Switch statement help

Discussion in 'Javascript' started by Mark, Jan 9, 2006.

  1. Mark

    Mark Guest

    Hi - how can I get a switch statement to look for a range of values?

    I have:

    function payCalc(field, field2)
    switch(field.value)
    {
    case 0-50: field2.value="lower band";
    case 51-99: field2.value="mid band";
    case 100-9999: field2.value="high band";
    }

    But this doesn't seem to work.

    Thanks for any help,

    Mark



    *** Sent via Developersdex http://www.developersdex.com ***
     
    Mark, Jan 9, 2006
    #1
    1. Advertising

  2. Mark

    Evertjan. Guest

    Mark wrote on 09 jan 2006 in comp.lang.javascript:

    > Hi - how can I get a switch statement to look for a range of values?
    >
    > I have:
    >
    > function payCalc(field, field2)
    > switch(field.value)
    > {
    > case 0-50: field2.value="lower band";
    > case 51-99: field2.value="mid band";
    > case 100-9999: field2.value="high band";
    > }
    >
    > But this doesn't seem to work.


    Switch is only handy for the godly that have read the specs.

    For us mere mortals, to lazy to read them, use:

    field2.value =
    (field.value<0) ? "out-of-range" :
    (field.value<51) ? "lower band" :
    (field.value<100) ? "mid band" :
    (field.value<10000)? "high band" :
    "out-of-range" ;



    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Jan 9, 2006
    #2
    1. Advertising

  3. Mark

    VK Guest

    Mark wrote:
    > Hi - how can I get a switch statement to look for a range of values?


    "switch" statement doesn't directly support ranges (like in VBS / VBA).
    But you can work around that by comparing the case with true:

    var num = 8000;

    switch(true) {
    case num>=0&&num<=51:
    alert(1); break;
    case num<=99:
    alert(2); break;
    case num<=9999:
    alert(3); break;
    default:
    alert('Out of range');
    }

    P.S. Unless you want to use (as suggested) more wide spread if-else if
    - else block.

    P.P.S. Also remember a very annoying cross-language bug in switch
    construct: it executes all underlaying branches unless you stop it with
    "break" statement.
     
    VK, Jan 9, 2006
    #3
  4. VK wrote:

    [snip]
    > P.P.S. Also remember a very annoying cross-language bug in switch
    > construct: it executes all underlaying branches unless you stop it with
    > "break" statement.

    [snip]

    Hello VK

    Just interested in why you consider this to be a "bug"?

    If I understand para 12.11 of the ECMA spec correctly
    (<URL:http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>,
    the production for a CaseClause or DefaultClause does not require the
    "break" Statement to be included.

    Further, leaving out the break statement can IMHO be useful sometimes
    (if for instance you want a given Statement to be executed for more
    than one case).

    So perhaps rather than "bug", do you mean: "source of potential errors
    for the unwary"?

    Regards

    Julian Turner
     
    Julian Turner, Jan 9, 2006
    #4
  5. Mark

    VK Guest

    Julian Turner wrote:
    > VK wrote:
    >
    > [snip]
    > > P.P.S. Also remember a very annoying cross-language bug in switch
    > > construct: it executes all underlaying branches unless you stop it with
    > > "break" statement.

    > [snip]
    >
    > Hello VK
    >
    > Just interested in why you consider this to be a "bug"?


    As I escaped the classical Comp.Sci. education I dare to call bug on
    bug and sh** on sh** if I feel so :))
    In the particular I do not consider a nonsense to magically become a
    lore just of being put in written (whoever wasted inks for it).

    This has nothing to do with ECMA though - it's all the same: up to the
    most pre-historic languages.
    Why do I think it's a bug? Because it goes against the common
    programming logic - and this is why people keep forgetting about
    break's.

    It's like having to put break after each function body so execution
    wouldn't jump on underlaying function:
    function foo() {
    // ...
    }
    break;
    function bar() {
    // ...
    }

    - and w/o break after foo() we would immediately execute bar(). A lot
    of sense? None. The same amount in
    case X : ...; break; // IMHO

    A perfect case of reversed logic for me. That would have some sense
    maybe to have a flag to "continue" execution of underlaying branches -
    but not a current annoyance twist.

    IMHO IMHO IMHO
     
    VK, Jan 9, 2006
    #5
  6. Mark

    Lee Guest

    VK said:

    >P.P.S. Also remember a very annoying cross-language bug in switch
    >construct: it executes all underlaying branches unless you stop it with
    >"break" statement.


    That's not a "bug", moron, it's designed that way intentionally.
     
    Lee, Jan 9, 2006
    #6
  7. Mark

    VK Guest

    VK wrote:
    > A perfect case of reversed logic for me. That would have some sense
    > maybe to have a flag to "continue" execution of underlaying branches -
    > but not the current annoyance twist.


    Also it breaks apart the boolean logic rules used in programming
    languages:

    case 10 :
    case 20:
    case 30:
    default:

    If switch happened to be equal 10, then after the first case: it also
    equals to 20 and 30 ! (by the execution logic) As if program on its one
    behalf would replace in:
    if (statement1)
    else if (statement2) {}
    else if (statement3) {}
    else {}
    all statements with (true). Think how much would you like it! ;-)
     
    VK, Jan 9, 2006
    #7
  8. VK wrote:

    > This has nothing to do with ECMA though - it's all the same: up to the
    > most pre-historic languages.


    Fair enough, fall-through (missing "break" statement) is a feature of
    C++ and Java as well - e.g.

    <URL:http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.11>

    > Why do I think it's a bug? Because it goes against the common
    > programming logic - and this is why people keep forgetting about
    > break's.


    You are entitled to your opinion. I thought, IHMO, it might just be
    worth considering identifying it as an opinion, to avoid possible
    confusion.

    Nevertheless, I would agree that "fall-though" (despite its uses) is
    not obvious from the structure of the switch statement, and so could
    perhaps lead to code that is harder to follow.

    Regards

    Julian Turner
     
    Julian Turner, Jan 9, 2006
    #8
  9. Mark

    Lee Guest

    VK said:
    >
    >
    >VK wrote:
    >> A perfect case of reversed logic for me. That would have some sense
    >> maybe to have a flag to "continue" execution of underlaying branches -
    >> but not the current annoyance twist.

    >
    >Also it breaks apart the boolean logic rules used in programming
    >languages:
    >
    >case 10 :
    >case 20:
    >case 30:
    >default:
    >
    >If switch happened to be equal 10, then after the first case: it also
    >equals to 20 and 30 !


    As usual, you've done a fine job of convincing us that you don't
    understand what you're talking about. The usage in your example
    doesn't tell us that the switch equals 10, 20, and 30, it tells
    us that 10, 20 and 30 are to be handled in the same way. It's
    just that sort of distinction that you seem to have trouble with.
     
    Lee, Jan 9, 2006
    #9
  10. Mark

    VK Guest

    Julian Turner wrote:
    > VK wrote:
    > > Why do I think it's a bug? Because it goes against the common
    > > programming logic - and this is why people keep forgetting about
    > > break's.

    >
    > You are entitled to your opinion. I thought, IHMO, it might just be
    > worth considering identifying it as an opinion, to avoid possible
    > confusion.


    Fair enough :)
    I guess from now on I'll be using terms not so heavily connected with
    the programming entities. Then the "switch" behavior could be called
    "common annoyance" (taken from the Firefox vocabulary).
     
    VK, Jan 9, 2006
    #10
  11. Mark

    VK Guest

    Lee wrote:
    > >case 10 :
    > >case 20:
    > >case 30:
    > >default:
    > >
    > >If switch happened to be equal 10, then after the first case: it also
    > >equals to 20 and 30 !

    >
    > As usual, you've done a fine job of convincing us that you don't
    > understand what you're talking about. The usage in your example
    > doesn't tell us that the switch equals 10, 20, and 30, it tells
    > us that 10, 20 and 30 are to be handled in the same way. It's
    > just that sort of distinction that you seem to have trouble with.


    Boy, that was just a short scheme to illustrate my point, not a code to
    execute.
    Sapienti sat - but if it's not the case then here a full scale code:

    <script type="text/javascript">
    var v = 10;
    switch (v) {
    case 10 : alert("v equals 10");
    case 20 : alert("v equals 20");
    case 30 : alert("v equals 30");
    default: alert("v is out of range");
    }
    </script>
     
    VK, Jan 9, 2006
    #11
  12. Mark wrote:

    "I have:
    function payCalc(field, field2)
    switch(field.value)
    {
    case 0-50: field2.value="lower band";
    case 51-99: field2.value="mid band";
    case 100-9999: field2.value="high band";
    }"

    Shouldn't the switch statement within the function also be enclosed in
    curly brackets ? Like this:

    function payCalc(field, field2)
    {
    switch(field.value)
    {
    case 0-50: field2.value="lower band";
    case 51-99: field2.value="mid band";
    case 100-9999: field2.value="high band";
    }
    }

    In addition to using a break or return statement after each case, isn't
    there also suppose to be a default case at the end ? Or is that not
    necessary ?

    Later, Art.
     
    X l e c t r i c, Jan 9, 2006
    #12
  13. Mark

    Lee Guest

    VK said:
    >
    >
    >Lee wrote:
    >> >case 10 :
    >> >case 20:
    >> >case 30:
    >> >default:
    >> >
    >> >If switch happened to be equal 10, then after the first case: it also
    >> >equals to 20 and 30 !

    >>
    >> As usual, you've done a fine job of convincing us that you don't
    >> understand what you're talking about. The usage in your example
    >> doesn't tell us that the switch equals 10, 20, and 30, it tells
    >> us that 10, 20 and 30 are to be handled in the same way. It's
    >> just that sort of distinction that you seem to have trouble with.

    >
    >Boy, that was just a short scheme to illustrate my point, not a code to
    >execute.
    >Sapienti sat - but if it's not the case then here a full scale code:
    >
    ><script type="text/javascript">
    >var v = 10;
    >switch (v) {
    > case 10 : alert("v equals 10");
    > case 20 : alert("v equals 20");
    > case 30 : alert("v equals 30");
    > default: alert("v is out of range");
    >}
    ></script>


    I don't see your point. GIGO.
    If you don't know how to use a construct, don't guess.



    >
     
    Lee, Jan 9, 2006
    #13
  14. Mark

    Evertjan. Guest

    X l e c t r i c wrote on 09 jan 2006 in comp.lang.javascript:

    > case 0-50: field2.value="lower band";
    > case 51-99: field2.value="mid band";
    > case 100-9999: field2.value="high band";
    >


    Besides all that is said,
    this means:

    case -49: field2.value="lower band";
    case -48: field2.value="mid band";
    case -9899: field2.value="high band";



    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Jan 9, 2006
    #14
  15. Mark

    Tim Streater Guest

    In article <>,
    (X l e c t r i c) wrote:

    > Mark wrote:
    >
    > "I have:
    > function payCalc(field, field2)
    > switch(field.value)
    > {
    > case 0-50: field2.value="lower band";
    > case 51-99: field2.value="mid band";
    > case 100-9999: field2.value="high band";
    > }"
    >
    > Shouldn't the switch statement within the function also be enclosed in
    > curly brackets ? Like this:
    >
    > function payCalc(field, field2)
    > {
    > switch(field.value)
    > {
    > case 0-50: field2.value="lower band";
    > case 51-99: field2.value="mid band";
    > case 100-9999: field2.value="high band";
    > }
    > }


    I suppose so, strickly, tho I wouldn't lay it out like that. Of course
    "case 0-50:" does not work.

    > In addition to using a break or return statement after each case, isn't
    > there also suppose to be a default case at the end ? Or is that not
    > necessary ?


    Only if you want one. If you leave it out and the value matches none of
    the cases then the switch does nothing. This can be useful depending on
    what you want.

    Certainly the break should be required. That does allow you to do this
    sort of thing:

    switch (value)
    {

    case 1:
    case 2:
    x = 3;
    break;

    case 15:
    x = 8;
    break;

    }

    In fact in this example you don't need the send break, but it's best to
    add it for the day when you add another case. Code that's gonna live
    more than 15 mins should be written with a view to future maintenance.

    -- tim
     
    Tim Streater, Jan 9, 2006
    #15
  16. "Julian Turner" <> writes:

    > VK wrote:
    >
    > [snip]
    >> P.P.S. Also remember a very annoying cross-language bug in switch
    >> construct: it executes all underlaying branches unless you stop it with
    >> "break" statement.


    > Just interested in why you consider this to be a "bug"?


    It's not a bug.

    It's just a very annoying and error prone feature that was introduced
    in C a long time ago, back when brevity was a bigger virtue than
    readability.

    > Further, leaving out the break statement can IMHO be useful sometimes
    > (if for instance you want a given Statement to be executed for more
    > than one case).


    You could allow several cases for each branch, without needing
    fallthrough between branches.

    The few algorithms that can actually use fallthrough does not justify
    the gazillion errors created by unwary programmers through the years.

    > So perhaps rather than "bug", do you mean: "source of potential errors
    > for the unwary"?


    I don't speak for VK, but I mean that.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jan 9, 2006
    #16
  17. Lasse Reichstein Nielsen wrote:

    [snip]
    > You could allow several cases for each branch, without needing
    > fallthrough between branches.
    >
    > The few algorithms that can actually use fallthrough does not justify
    > the gazillion errors created by unwary programmers through the years.


    Fair point. I have found a few instances where fall-through was a
    potentially useful option, but have tended to avoid it as in all cases
    there were clearer alternative ways of doing the same thing.

    Regards

    Julian Turner
     
    Julian Turner, Jan 9, 2006
    #17
  18. Mark

    Tim Streater Guest

    In article <>,
    Lasse Reichstein Nielsen <> wrote:

    > "Julian Turner" <> writes:
    >
    > > VK wrote:
    > >
    > > [snip]
    > >> P.P.S. Also remember a very annoying cross-language bug in switch
    > >> construct: it executes all underlaying branches unless you stop it with
    > >> "break" statement.

    >
    > > Just interested in why you consider this to be a "bug"?

    >
    > It's not a bug.
    >
    > It's just a very annoying and error prone feature that was introduced
    > in C a long time ago, back when brevity was a bigger virtue than
    > readability.


    It's not an annoying and error-prone feature. It's very useful. It adds
    flexibility. I contrast this with Pascal, which had a number of shitty
    irritations such as this (i.e., not needing the break as it was
    inherently there) in the name of language "purity".

    -- tim
     
    Tim Streater, Jan 9, 2006
    #18
  19. Mark

    Lee Guest

    Lasse Reichstein Nielsen said:

    >The few algorithms that can actually use fallthrough does not justify
    >the gazillion errors created by unwary programmers through the years.


    It's a very handy way to identify people who don't know how to
    read a manual. Programmers should avoid guessing how features
    work.
     
    Lee, Jan 9, 2006
    #19
  20. Mark

    Lee Guest

    X l e c t r i c said:
    >
    >Mark wrote:
    >
    >"I have:
    >function payCalc(field, field2)
    >switch(field.value)
    >{
    >case 0-50: field2.value="lower band";
    >case 51-99: field2.value="mid band";
    >case 100-9999: field2.value="high band";
    >}"
    >
    >Shouldn't the switch statement within the function also be enclosed in
    >curly brackets ? Like this:
    >
    >function payCalc(field, field2)
    >{
    >switch(field.value)
    >{
    >case 0-50: field2.value="lower band";
    >case 51-99: field2.value="mid band";
    >case 100-9999: field2.value="high band";
    >}
    >}
    >
    >In addition to using a break or return statement after each case, isn't
    >there also suppose to be a default case at the end ? Or is that not
    >necessary ?


    RTFM
     
    Lee, Jan 9, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. _
    Replies:
    1
    Views:
    426
    Enrique
    Feb 19, 2004
  2. vic

    switch case statement

    vic, Mar 3, 2004, in forum: Java
    Replies:
    9
    Views:
    5,899
  3. Replies:
    21
    Views:
    1,068
    Giannis Papadopoulos
    Aug 2, 2005
  4. bthumber
    Replies:
    5
    Views:
    426
    Alexey Smirnov
    Jan 29, 2009
  5. Switch Within A Switch

    , Apr 22, 2006, in forum: Javascript
    Replies:
    7
    Views:
    115
    Lasse Reichstein Nielsen
    Apr 22, 2006
Loading...

Share This Page