Many years ago, I took part in the development of a taxi-hailing mobile app that is still widely used today. I don’t know what kind of code they’re running now, but in those early days, the driver assignment code –if I remember it correctly– was similar in spirit to the grossly simplified example that follows. There are five levels of nested if statements in less than 30 lines of code. It doesn’t look so bad, some might say, but it’s not difficult to imagine how complicated this code can become with just a few more checks…
This doesn’t get rid of the if statements. It hides them.
It doesn’t hide. It makes them happen first and, here’s the important bit, closes their scope quickly.
The scope is irrelevant it’s a single function class as presented. It was a single method that they broke out “to hide the ifs”. Then they just used compiler specialties to remove the word ‘if’ from the assignments. The comparisons are still there and depending on the execution path those constants may not be so constant during runtime.
It has conditionals not but actual if statements. Not really different in functionality but a more consistent style.
They’re still ifs. They’ve just been lambda’d and assigned to constants.
branching ≠ if ≠ conditional
They’re all related but can’t just be used interchangeably. “if” is a reserved keyword to indicate a specific syntax is expected. It’s not the semantics the author was trying to change, it’s the syntax, and the overall point is that you aren’t always required to use the specific “if” syntax to write code just like you’re not required to use “while” to achieve looping.
If you decompile that code you won’t get lambdas. You get ifs. Because that is how the hardware is build. Ifs/ands/Ors that is what computing is built on. Everything else is flavor.