T
here are many ways to think through the flow of a program, and times when certain constructs like switch statements are a nice option, even in a language with no syntactical support for it, per se. Philippe Mougin was discussing just such options in F-Script back in the Oughts. I had a need for switching in F-Script, and came up with a few versions that I found useful.
First, let me point out the very graceful construct mentioned by Philippe in his blog. As traditional switch-case logic is about starting with a dictionary of key/block pairs and using some variable to select among them, F-Script already can handle this association gracefully:
(Philippe breaks his up into two statements for clarity. Either way seems nice.) Here, if a value is a perfect match for myVariable, the code block associated is returned by the objectForKey: method and e-value-ated. Graceful, with only the slightly busy-looking starting (#{ syntax.
It lacks two things from switch logic in other languages: the else/default case; and the ability to "fall-over," for either covering multiple cases or for cascading effects. I very rarely like to use the latter feature (logic intent is often hard to make obvious), but I would like to have an else-case default block run when all else doesn't match.
In this first variation, I make a block called "switch" that first evaluates the selected code blocks exactly as above, but also returns a single YES/NO value, made up of or-ing all the YES/NO responses to check of the value against any key. So, if any key matches, the switch block returns YES; if all are misses, it returns NO, which you can then use to optionally trigger an else-case code block:
Ever so slightly more complicated syntax gains an else case, includes the word "switch" to perhaps make the intent slightly clearer, and pops the variable which triggers the cases on top.
The next variation has the advantage of returning the results of the evaluated block, in case you'd like to use it for something instead of just executing blocks.
Note that Method 2 takes in 3 arguments, taking away the need to wrap the switch block in parentheses, but swapping the more readable ifFalse: for value: at the end. Of course, using the result is entirely optional, but now not including an else block is not optional.
Lastly, (the first variation that I made and my favorite) is something not technically a switch-case logic, but can be used for it. It's a generalization that allows completely arbitrary sets of conditions as keys for each block of triggerable code. Here one does not even need to think in terms of a variable which selects among the conditions, though one can decide to use it that way. It has several advantages, but since the logic behind it is different enough, I call the block "conditional" instead of "switch" as above:
The conditional block itself only takes one dictionary for its argument, and again makes available the optional ifFalse: logic at the bottom because it returns the or-ed condition results as with Method 1.
How this works is by wrapping each condition1, condition2, etc, in blocks. This makes each one unique, even if their evaluation is the same*. This gives a great deal of flexibility. One can use it for switch-like logic, but one can also cover many kinds of cases, related or not. It is perhaps too flexible for some, as some crazy contortions can become tempting. But if you try to keep tight-related conceptual operations per such logic dictionary, it can enhance little moments in your code. Yes, it's just a graceful if-then set, but isn't all of this, and it is graceful.
(* — It is a touch dangerous because even two blocks with the exact same condition are not the same block, so the code relies on your oversight to not accidently put in multiple responses to the same condition. Sorting the dictionary lines can make most bugs along these lines easy to find.)