I'm having a discussion on another forum about reversing the standard if/then/else construct
if (something is true) {
do a thing
} else if (someotherthing is true) {
do another thing
} else {
print "nothing was true"
do failsafe stuff
}
to
if all else fails {
print "nothing was true"
do failsafe stuff
} else if (something is true) {
do a thing
} else if (someotherthing is true) {
do another thing
}
Is anyone able to modify the Multi-branched Conditional library to implement this (or another method entirely)
I'm also having trouble. The if all else fails block is imported, but not its dependencies. The definition is empty and the catch and throw blocks are not imported.
I've managed to mangle the code in the Node-RED switch node (its equivalent of if / else if / else) - this was the other place I mentioned in the OP
I'm not sure my change will be accepted but at least I've proved it's possible to do
FYI The reason for wanting to do this is to avoid crossing wires. Crossing the wires doesn't actually cause an issue at all but they don't look nice and make it harder to follow program flow
For almost all of the book, people were pretty dang sure Mr. Oz was, in fact, a wizard. Then people learned stuff and realized they could pull it off too :~)
Though unfamiliar with the discussion on another forum @cymplecy refers to,
I'd like to elaborate why in my view is superior to , by far
(and therefore deserves to be included into the "Iteration, composition" or "Multi-branched conditional" library! - BTW IMO the latter ought to be included in the former).
Pros of IF ALL ELSE FAILS over CASES IF THEN ELSE
Most importantly, a default action fundamentally differs from the (ELSE) IF THEN-clauses. Therefore it makes sense to feature it by putting it first, as is done in IF ALL ELSE FAILS.
Secondly, the code of IF ALL ELSE FAILS is naturally (i.e. without any shortcuts) a tad shorter, which is generally a good thing (Occams Razor and all that).
Thirdly, IF ALL ELSE FAILS needs only one companion: , and nothing .
Last but not least, the user is far less likely to forget about defining a default action.
All else
IF ALL ELSE FAILS is quite a witty designation; however for clarity one might consider renaming the blocks: , and (or ), respectively.
Incidentally, from studying this topic I've learned that any predicate can be included in a case block, even if it doesn't accomplish any action: simply to exclude that case from further evaluation. Wasn't aware of that.
I did that on purpose - just to show that the Four Pro's of your IF ALL ELSE FAILS proposal vs. the Snap! library's current CASES implementation are independent of where the default action is situated within the block.
Perhaps a (primitive or library-canonized) block will ease the pain (, and even more so , will do as well, but a separate COMMENT block would be better, also for stimulating Snap! users to document their code, which is a Good Practice, whatever Hon. Oz may think about influencing user practices ).
So, what do you say ... change this topic into a Feature Request? (or was that only for Snap! primitives? if so, where can library suggestions be "officially" made? o, well, @bh probably reads everything posted on the forum anyway - hi, there! )