My ECMA Proposal : make switch useful

The Switch
The Switch
[update 2014 Nov 04]

Please read this post in conjunction with

http://dbj.dbjdbj.org/2014/09/07/javascript-with-proper-if/

[end of update]

The other day on jQuery forum, I spotted a code like this one:
(first published 06JUN09)


Unfortunately, for some, this is “too many keystrokes” … And peculiarly (then very young and rushed) Mr B. Eich forgot to make a result of the switch available, so this was not possible in javascript:

As far as JavaScript parsers (some of them) are concerned “switch” above is an “unexpected token” error. Added peculiarity is that the following code parses OK,

The latest statement is the switch and it returns “red”, indeed. And yes You are free to try and “give it” to the return statement. That might not work too.

One roundabout way is to get to the return value of the switch, with eval(), like this :

The issue is that switch; statement, after all, returns the value, but it is not a legal ‘rvalue’ in some JavaScript engines. At the moment. The eval() trick is not very useful and looks somewhat dodgy. So some developers have concluded they “must help” everyone with the function similar to this:

It has to be said that this is directly inspired by the LISP (COND …) construct. And, by now the excitement in the forum is high indeed because one can safely write this:

Also much cleaner and shorter than the very first snippet in this post. Quick and dirty, and very workable, cond function is this:

Example usage:

For some, this is “Awesome”, while for others this is “obfuscation”. Personally, I like it but I vote for ECMA to simply allow assignment with the ‘switch’ statement to be a legal “rvalue”. That is: make the return value of the switch statement available for assignment:

Although. (It has to be said) I rather like cond() and I think it delivers much more readable robust code. Thus I have added this for everyone to use, to the NPM in the form of dbj.cond() .

Enjoy
–DBJ

Update 2010.Jan.10

Ben Alman made this idea into a useful jQuery plugin, here: http://benalman.com/projects/jquery-cond-plugin/

8 Replies to “My ECMA Proposal : make switch useful”

  1. Update
    Interesting (probably for some readers) is that this cond() function could replace each and every switch() and of course if … then … else … if … else …, “cascades” , which obviously will lead to a more compact code. But not necessarily a faster one.
    Although I have not tought yet about optimising the cond() function …

  2. @bleroy Thanks for reading. I am not after “evaluating switch” , I am rather after ECMA comitee making standard switch an “rvalue”. But Your swtch() is clever nevertheless.

  3. I understand, and I agree that extending the EcmaScript switch to support this would be ideal. Can’t see a downside to it really. Looks like a simple oversight, and there are no back-compat issues that I can think of.

    1. @Juan Mendes: Thanks for reading and commenting.

      There is also a sequel to this “story” here: https://dbj.org/blog/2013/07/10/dbj-cond/

      With a link to the GITHUB project.

      In any case I approve of you making an effort. But please do not forget one simple truth:

      JavaScript is LISP with a C syntax 🙂

      After reading your article I do still prefer a first idea and solution. Mine that is.
      I think it is simpler and easier to type and dbj.cond() also has no problems with using functions as parameters. Which are actually necessary vs LISP, as explained here:
      http://dbj.dbjdbj.org/2014/09/07/javascript-with-proper-if/

      1. I know, I know… “JavaScript is LISP with C syntax” Since I prefer C/JavaScript syntax, I decided to offer the same behavior with C/JavaScript Syntax for those of use that prefer JavaScript 🙂 Now that I’ve seen your version of cond that accepts functions, I think they are pretty much equivalent. Here’s another article that doesn’t create a cond function, but talks about using objects for switches: http://toddmotto.com/deprecating-the-switch-statement-for-object-literals/

        1. @Juan .. I do believe classes, polymorphizm and inheritance are not meant to be emulated in JavaScript. So this is first line we draw 🙂

          Second toddmotto article “I do not dig” … I see nothing “nice and easy” in his proposal?

          AFAIK, Bertrand Le Roy has proposed simple and less obfuscated, object literals based solution already , here: https://gist.github.com/anonymous/3975291

          Thanks for your comments anyway 🙂

Comments are closed.