I always put the 'otherwise' option last, i don't think it should be put anywhere else.
The possibility of re-ordering the other options would be nice to have.
Also, in my opinion 'Stopping after first match' should be the default option.
I'm only doing special processing for Rule 0 at the moment but will adapt it to handle any position 
Well, You wouldn't have to move it if you didn't want to - this is just to help out people like me who don't want to cross their streams
Well, the ability to assign which rule goes to which output would be the most useful change but probably requires the most coding changes. Also, would be a bit of nightmare to debug if more than a few options
This FR, to just allow the otherwise to work in another position, requires little coding change (so far anyway) and hopefully wouldn't cause any compatibility problems with existing flows
Each to their own preference It would make the switch node act in a more "standard" if / else if/ else if ... /else way but in practice I, personally, rarely select that option
Of course you can just re-order them today by dragging them into the order you want... but they get evaluated in order from top to bottom - so you have to make sure the logic makes sense when in the new order (or don't stop after first match ) - hence the current problem/issue/discussion about the evaluation of "otherwise"
actually that may be best solution (at least for now) - nice.
1 Like
I didn't know that. Thanks!
That's why I think 'Otherwise' should always be the last option.
I would even welcome it if this was enforced by the settings dialog.
Agree. "Otherwise" (aka else) should always be last and IMO would make more sense being a simple checkbox option along the lines of [x] output when no rules match and would always be the last output.
5 Likes
#Phew I'll revert my changes back
I was only half way thru and it was proving a bit more difficult than I thought
For those having issues with the idea of having a working "otherwise" at the top - are you opposed to the whole idea on principle or would you be more accepting if it was explicitly labelled something else?
You've framed it as an either/or. Not sure it is quite that simple.
I think that the concept is confusing to people who need/want to work with programming languages and formal logic - I'm not aware of anything else that provides this form.
But I can see that it might help a small subset of people who are not programmers and who's thought processes are not necessarily "top-down" oriented.
Personally, I much prefer Steve's suggestion of having a simple checkbox that turns on an otherwise option that is always pinned at the bottom.
My whole driving force is to help those people
1 Like
Just playing catch up on this whole thread.. but as I write I see @TotallyInformation has posted along the lines of my gut feeling here.
When you have 'check all rules' enabled (the default), you can have multiple 'otherwise' rules, and each acts based on the rules above it.
For example, given the rules:
== A== Botherwise== C== Dotherwise
If you inject 'A' you will get an output on 1 and 6
If you inject 'C' you will get an output on 3 and 4
Confusingly, if you inject 'RANDOM', you only get an output on 3 - I expected that to trigger both 3 and 6.
So there is already some inconsistent (and possibly incorrect) behaviour around the otherwise rule that has been there for years.
But regardless of that, this proposal would change what an otherwise rule at the top of the list does - which is a breaking change for existing flows. That means we have to be really really sure this is solving a real issue. I'm not sure "avoiding crossed wires" is a good enough reason to potentially break flows.
1 Like
I'm startled to discover that the default in a Javascript switch statement is allowed to be the first clause.
https://www.w3schools.com/js/js_switch.asp
And a 'default' clause cannot appear more than once in a 'switch' statement.
1 Like
So changing my FR to add in a "default" rule that can placed at the top
Me too! I always assumed it just worked through the code doing the tests in the order given. It must effectively move the default down to the end.
However, if you remove the central otherwise then injecting A gives a result only on op 1, so adding the the extra otherwise causes an output on 6!
My suggestion would be to only allow otherwise at the end (which I would have thought is unlikely to affect any existing flows), and if it is thought useful then allow a default rule at the front as suggested by @cymplecy which operates the same way as the js Switch. The change to the otherwise rule could be considered a bug fix rather than a change.
I think we all THINK that no-one is currently putting the "otherwise" anywhere else except the bottom
As it's very hard to imagine that someone has it in another slot except by mistake
It's up to Nick to assess such as risk
I'm nearly there with a contrib alternative switch node POC to do that
And here is my node-red-contrib-alternate-switch node (not publishing it to npm) for anyone to try/test it out
in your userDir (~/.node-red) run the following:
npm install cymplecy/node-red-contrib-alternate-switch
(or so I think anyway)
[edit 21Feb2023] Added ability to handle "stop after 1st match" option correctly
I'm with Simon -- perhaps if it was called "Default" then we wouldn't expect it at the end?
That's typical for programming anyway... set some defaults, then override them for specific cases later. So I could expect it to be first in the list.
Of course, how it works with the "Stop after first match" vs. "Evaluate all" option could get tricky.
OOPS! I didn't read far enough to see Nick's and Colin's answers... so never mind
2 Likes
Interesting discussion...
If for one sec, we forget about IT and just consider what it would be in the real life while speaking our human language (personally French).
From a grammar point of view, it would be extremely confusing to start a sentence with autrement/otherwise without any preceding information context.
Typically, autrement/otherwise in human language, IMHO, is something you do if all other hypothesis are wrong. In order to know they are wrong you have to tell them before the otherwise.
For once 
programming language can match our human language...
Otherwise is something you would do after:
- you know all the choices
- they don't match
I like when a program behaves like a normal human would process this
Or at least with my non existant programming skills (hence my pleasure in using NodeRed) that's what I do.
My 2 cents...
Tonight, I'll have a beer if I have some in the fridge. Otherwise water. Not the other way round.
4 Likes
This is my current proposal
i.e. I will have water unless there is beer or wine in the fridge
