# An else before if block

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)

just reverse the inputs of the case

Struggling to import this Brian - can you re-export please?

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'm guessing what happened was, he made the block, but didn't hit apply before creating the script pic.

Yeah. Duh, I'm an idiot. Here you go:

Great block! Definitely worthy of the Iteration … library.

Doesn't quite work for me - says payload = a but then give error

works as expected for payload = c

Sigh, I should really learn to debug my code before I post it, even if I think it's obvious.

It's a relief for us muggles that the wizards themselves muck up from time to time

I'm a wizard in the same sense as the Wizard of Oz.

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.

Kudos
@cymplecy!

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 think (in Snap!) the block looks wrong (e.g there nothing in the 1st slot) if no default action is wanted/required.

I just wanted to show that putting the else clause at the beginning could be a lifestyle choice and that having it at the end wasn't set in stone

But in Snap! (and 99% of other languages) I think the traditional way of (optionally) putting it at the end is better.

If you look at some of comments on the Node-RED forum, I think my suggestion is causing cognitive issues for some of them

@cymplecy: You're too modest! Who cares about 99%?

Still, if you keep worrying about other programmers who might judge "nothing" in the first slot to "look wrong", why not try the following version?

To my mind- you've just demonstrated putting the else at the end

But in other news from the other place, someone pointed out that JavaScript itself is happy to have the "if all else fails" at the beginning

An empty C-slot does look wrong in Snap! - anyone would think that there was something missing and would be reporting it as a bug

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 ).

influencing users' programming practices

("We are not in the business of preventing users from doing anything!") - OK, I'm aware that this may be a strawman fallacy, since preventing bad practice and stimulating good practice are not exactly the same thing.

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! )

I think for any chance of getting a block like this into the libary, we'd have to show that it was worth it

And, at the moment, its just a different syntax on the existing constructs.

I don't think it brings any extra value

Unlike in Node-RED where it helps things look nicer and therefore serves a useful purpose