Binary Operator Rant



  • @Sutherlands said:

    I did read it, tyvm.  I, however, did not assume that a bug in a+b*c+d had anything to do with functions.  A good reason to NOT assume that is because adding parenthesis fixed the problem.  Had it been related to operands, parenthesis would not have fixed it (although i could be wrong on this part).  Another reason to not assume that is because none of those are functions, and had the OP meant for them to be functions, he would have made them functions. 

    @Weng said:

    a bug caused by C# deciding that a+b*c-d (okay, in reality it was WAY more complex than that)

    Emphasis added.



  • @Sutherlands said:

    I did read it, tyvm.  I, however, did not assume that a bug in a+b*c+d had anything to do with functions.  A good reason to NOT assume that is because adding parenthesis fixed the problem.  Had it been related to operands, parenthesis would not have fixed it (although i could be wrong on this part).  Another reason to not assume that is because none of those are functions, and had the OP meant for them to be functions, he would have made them functions.  And obviously, since I wrote down what the correct order of precedence was, and the correct result, I thought that it had to do with simple arithmetic precedence.

    tl;dr - If you're going to make assumptions about what other people said, state your assumptions in your post.  Don't assume that everyone else made the same assumptions as you.

    Emphasis added.



  • <FONT face=CMMI12>

    btw, x+iy=u^2-v^2+2iuv is way more complex than that, but doesn't involve functions.</FONT><FONT face=CMMI12>

    </FONT>


  • @Sutherlands said:

    I did read it, tyvm.  I, however, did not assume that a bug in a+b*c+d had anything to do with functions.  A good reason to NOT assume that is because adding parenthesis fixed the problem.  Had it been related to operands, parenthesis would not have fixed it (although i could be wrong on this part).  Another reason to not assume that is because none of those are functions, and had the OP meant for them to be functions, he would have made them functions.  And obviously, since I wrote down what the correct order of precedence was, and the correct result, I thought that it had to do with simple arithmetic precedence.

    tl;dr - If you're going to make assumptions about what other people said, state your assumptions in your post.  Don't assume that everyone else made the same assumptions as you.

    Emphasis multiplied.



  • *waits for someone to underline it*



  • @Sutherlands said:

    *waits for someone to underline it*
     

    @Someone You Know said:

    @Sutherlands said:

    I did read it, tyvm.  I, however, did not assume that a bug in a+b*c+d had anything to do with functions.  A good reason to NOT assume that is because adding parenthesis fixed the problem.  Had it been related to operands, parenthesis would not have fixed it (although i could be wrong on this part).  Another reason to not assume that is because none of those are functions, and had the OP meant for them to be functions, he would have made them functions.  And obviously, since I wrote down what the correct order of precedence was, and the correct result, I thought that it had to do with simple arithmetic precedence.

    tl;dr - If you're going to make assumptions about what other people said, state your assumptions in your post.  Don't assume that everyone else made the same assumptions as you.

    Emphasis multiplied.


     There you go.



  • Operands in an expression are evaluated from left to right. For example, in F(i) + G(i++) * H(i), method F is called using the old value of i, then method G is called with the old value of i, and, finally, method H is called with the new value of i. This is separate from and unrelated to operator precedence.

    This looks like the Real WTF to me though. Consider:

    x = 5; 
    false && (x++ > 0);

    So, what's [code]x[/code] afterwards, 5 or 6?

     



  • @PSWorx said:

    x = 5; 
    false && (x++ > 0);

    So, what's <font face="Lucida Console" size="2">x</font> afterwards, 5 or 6?

     

    Should be 5 as short circuiting, so the part after the && is never evaluated.



  • That is correct., however the following will yield 6. So the developer has complete control over the evaluation of the RHS.

     x = 5;
    false & (x++ > 0);    // Note the SINGLE Ampersand!



  •  @locallunatic said:

    @PSWorx said:

    x = 5; 
    false && (x++ > 0);

    So, what's <font size="2" face="Lucida Console">x</font> afterwards, 5 or 6?

     

    Should be 5 as short circuiting, so the part after the && is never evaluated.

    Reminds me (backwards, I admit) of this trick they use in JS Prototype lib source to initialise the might-be-undefined parameter "i" :

      function indexOf(item, i) {
        i || (i = 0);
        var length = this.length;
        if (i < 0) i = length + i;
        for (; i < length; i++)
          if (this[i] === item) return i;
        return -1;
      }


     



  •  @locallunatic said:

    Should be 5 as short circuiting, so the part after the && is never evaluated.

    Hmm, my bad, I guess I made exactly that mistake the doc tried to warn people about. Oh well, derp!

     @toshir0 said:

    Reminds me (backwards, I admit) of this trick they use in JS Prototype lib source to initialise the might-be-undefined parameter "i" :

      function indexOf(item, i) {
        i || (i = 0);
        var length = this.length;
        if (i < 0) i = length + i;
        for (; i < length; i++)
          if (this[i] === item) return i;
        return -1;
      }


    Yeah, Google is also notorious for that. For some reason they love to write 

    condition && (action1, action2, action3);

    Instead of

    if (condition) {action1; action2; action3}; 

    in various of their libraries. In order to ...  save two bytes? Look cool? I have no idea.

     

     



  • @PSWorx said:

    [quote user="toshir0"]

    Reminds me (backwards, I admit) of this trick they use in JS Prototype lib source to initialise the might-be-undefined parameter "i" :

      function indexOf(item, i) {
    i || (i = 0);
    var length = this.length;
    if (i < 0) i = length + i;
    for (; i < length; i++)
    if (this[i] === item) return i;
    return -1;
    }


    Yeah, Google is also notorious for that. For some reason they love to write 

    condition && (action1, action2, action3);

    Instead of

    if (condition) {action1; action2; action3}; 

    in various of their libraries. In order to ...  save two bytes? Look cool? I have no idea.

     

     

    [/quote]

    Now the || one I don't get. Just how is that better then i = i || 0, which is actually shorter, not to mention making more sense as setting i.



  • Repeat after me..

    C#  -  both "&&" and "||" short-circuit - "&" and "|" do not.

    C++ - both "&&" and "||" short-circuit UNLESS you overload them, in which case they do NOT.



  • @locallunatic said:

    @Sutherlands said:

    *waits for someone to underline it*
     

    @Someone You Know said:

    @Sutherlands said:

    I did read it, tyvm.  I, however, did not assume that a bug in a+b*c+d had anything to do with functions.  A good reason to NOT assume that is because adding parenthesis fixed the problem.  Had it been related to operands, parenthesis would not have fixed it (although i could be wrong on this part).  Another reason to not assume that is because none of those are functions, and had the OP meant for them to be functions, he would have made them functions.  And obviously, since I wrote down what the correct order of precedence was, and the correct result, I thought that it had to do with simple arithmetic precedence.

    tl;dr - If you're going to make assumptions about what other people said, state your assumptions in your post.  Don't assume that everyone else made the same assumptions as you.

    Emphasis multiplied.


     There you go.

    I tried clicking on the link above but nothing happens.

     



  • @MiffTheFox said:

    @PSWorx said:
    @toshir0 said:

     

    Reminds me (backwards, I admit) of this trick they use in JS Prototype lib source to initialise the might-be-undefined parameter "i" :

      function indexOf(item, i) {
        i || (i = 0);
        var length = this.length;
        if (i < 0) i = length + i;
        for (; i < length; i++)
          if (this[i] === item) return i;
        return -1;
      }


    Yeah, Google is also notorious for that. For some reason they love to write 

    condition && (action1, action2, action3);

    Instead of

    if (condition) {action1; action2; action3}; 

    in various of their libraries. In order to ...  save two bytes? Look cool? I have no idea.

     

     

    Now the || one I don't get. Just how is that better then i = i || 0, which is actually shorter, not to mention making more sense as setting i.

    If "i" is defined, the line is not even an assignation, it must be quicker than even a tautological assignation...

     



  • @MiffTheFox said:

    Now the || one I don't get. Just how is that better then i = i || 0, which is actually shorter, not to mention making more sense as setting i.

    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7. Google "recommends" using that little gem in Google Analytics, apparently oblivious or uncaring that it doesn't work on a significant number of sites, on a significant number of browsers. (Their incorrect version is, IIRC, "var _gaq = _gaq || []];" I just recently fixed it for a client by writing it as "if( !_gaq ){ _gaq = []] };" Sure, it's 2 extra characters after minification, but my version has the slight advantage of actually working on all browsers.)


  • ♿ (Parody)

    @blakeyrat said:

    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7. Google "recommends" using that little gem in Google Analytics, apparently oblivious or uncaring that it doesn't work on a significant number of sites, on a significant number of browsers.

    I'd guess they consider that a feature as they try to kick people into the present, browser-wise. I wonder how much their lack of support has actually changed what people use.



  • @boomzilla said:

    @blakeyrat said:
    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7. Google "recommends" using that little gem in Google Analytics, apparently oblivious or uncaring that it doesn't work on a significant number of sites, on a significant number of browsers.
    I'd guess they consider that a feature as they try to kick people into the present make people use Chrome. I wonder how much their lack of support has actually changed what people use.
     

    I'm intrigued though. I had always thought that expressions like that are so close to the JS core that you couldn't do anything wrong with them. How did IE manage to botch that one nevertheless? Please tell!



  • @blakeyrat said:

    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7.
     

    Please clarify.



  • @MiffTheFox said:

    And VB still uses the same operators for binary and boolean operations, not that it doesn't have worse annoyances.

    VB (or atleast VB6) doesn't have boolean operators. They always do binary.



    The fun starts when you do "1 AND 2" which is 0 and thus false. And True is defined as -1 in VB, however, if you get a boolean back from api's they are sometimes "1" internal, instead of "-1", making them a false true. They evaluate to true, but if you NOT them they still evaluate to true. And if you compare them to true they are false. Confused yet? Good.



  • @boomzilla said:

    @blakeyrat said:
    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7. Google "recommends" using that little gem in Google Analytics, apparently oblivious or uncaring that it doesn't work on a significant number of sites, on a significant number of browsers.

    I'd guess they consider that a feature as they try to kick people into the present, browser-wise. I wonder how much their lack of support has actually changed what people use.

    It also failed in IE8, IIRC, so... I doubt it.

    Also it's an analytics program, so breaking on old browser versions would be kind of counter-productive.

    @dhromed said:

    Please clarify.

    I'd be lying if I told you I tracked down the exact error. Whenever I set up a simplified test case, the error didn't reoccur, so I think it might be due to some other piece of script on the client site, or perhaps due to a particular quirk mode IE was in at the time.

    Google Analytics works by setting up an array as a queue of instructions to send to the analytics back-end. So the normal use is they create the array, _gaq, and then you can .push() commands and their parameters into it.

    When your site loads the ga.js script, it puts its _gaq in the global window scope on its own. If you start queuing commands before ga.js loads, you need to ensure _gaq is an array in your own code, which is what the above line of code does.

    So anyway, the code looked vaguely like this:

    <script src="https:google-analytics.com/ga.js">
    
    (tons of other .js files, HTML and <script> tags, IIRC I counted 15 .js files on this crazy-ass site)
    
    <script>
    
    var _gaq = _gaq || []]; // JS debugger shows "var _gaq" nulls previous contents of window._gaq;
    _gaq.push( [SomeGACommand, SomeGAParams] );
    
    </script>

    Now like I said, I wasn't able to produce a working stripped-down test case. The above code will likely work if you try it on a blank site.

    My guess is that in those browsers, under some circumstances, a random script tag doesn't have its own variable scope, and thus the first part of that line "var _gaq" isn't creating a local version of the window-scope variable, but is in fact replacing the existing window-scope variable with a new one. And since the code in ga.js already ran, it wipes out all the normal stuff they crap in that variable, and Google Analytics never runs. At least, that's what the debugger says it happening.

    The other possibility is that one of the various other script files loaded was doing something to cause the error...

    Anyway, please call me stupid and tell me how wrong all my code is now.

    But the important thing to remember is that the client team had been struggling with this problem for weeks, and after sending it to me I managed to give them a fully-tested solution (if not fully explain it) in less than 4 hours... so no matter how much I suck, the client sucks an order of magnitude worse, and our company and team ended up looking like super geniuses.


  • ♿ (Parody)

    @blakeyrat said:

    Anyway, please call me stupid and tell me how wrong all my code is now.

    But the important thing to remember is that the client team had been struggling with this problem for weeks, and after sending it to me I managed to give them a fully-tested solution (if not fully explain it) in less than 4 hours... so no matter how much I suck, the client sucks an order of magnitude worse, and our company and team ended up looking like super geniuses.

    Meh...sounds like the standard process of debugging to me, especially when you've exposed code to the random environments created by users. The obvious-seeming cause often isn't.


  • @blakeyrat said:

    Anyway, please call me stupid and tell me how wrong all my code is now.
    @blakeyrat said:
    Filed under : Here comes the mockery
    *whistles very casually*



  • The only time a "language" irritates me with order of operations is Excel.

    Excel considers

    =5++5

    =5--5

    =5+-5

    =5+-5^2

    etc. as valid syntax. I realize this is perhaps "natural" for finance people, but as an engineer it drives me mad.



  • @boomzilla said:

    @blakeyrat said:
    If we're talking JS, careful. var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7. Google "recommends" using that little gem in Google Analytics, apparently oblivious or uncaring that it doesn't work on a significant number of sites, on a significant number of browsers.

    I'd guess they consider that a feature as they try to kick people into the present, browser-wise. I wonder how much their lack of support has actually changed what people use.

    So far they haven't been able to push me away from Opera, despite Google Docs having some subtle yet irritating UI breakdowns. The hour tracking system we use at work doesn't work at Opera either, but that has just resulted in me getting filing my hours only about once a month (since I need to open another browser for it). Haven't gotten around to writing a native application utilizing the REST API yet.



  • @too_many_usernames said:

    The only time a "language" irritates me with order of operations is Excel.

    Excel considers

    =5++5

    =5--5

    =5+-5

    =5+-5^2

    etc. as valid syntax. I realize this is perhaps "natural" for finance people, but as an engineer it drives me mad.

    What's wrong with those? The first one uses an unary plus operator (which is a no-op), and parses as 5+(+5). Second one is 5-(-5), etc.



  • I imagine they would work in c/c++/c# if they didn't have the ++, -- operators.



  • @blakeyrat said:

    var i = i || 0 has hidden depths that can make it fail hard on IE 6 and IE 7.

    @blakeyrat said:

    I wasn't able to produce a working stripped-down test case.

    Against better judgement, I had a look at the specs and blew my mind in the process. Anyway, here are my findings. Disclaimer: This may or may not be related to your problem at all.

    If you use that statement inside a function, it does not read a global variable. If I understand ECMA-262 10.5 correctly, it does not matter where exactly var declarations occur, only if they occur somewhere in a function. Thus, inside a function body, var x=x||[]];, var x; x=x||[]]; and even x=x||[]];var x;var x; all have the same effect. At the start of a function, parameters are assigned their respective values and all other declared (local) variables are set to undefined (initialization happens later). The x in the examples is therefore always set to an empty array, without touching the caller's x.

    If you use that statement inside eval, things get really weird. I'll just post a short example, because I have no idea how to explain the results.

    <script type="text/javascript">
    //"use strict"
    window.foo = 1;
    alert(foo);
    eval("var foo = foo || 2; alert(foo);");
    alert(foo);
    </script>

    Internet Explorer 8.0.6001.18702 will print 1,2,2. Firefox 4.0.1 will print 1,1,1. If you uncomment the first line, Firefox will print 1,2,1 instead.

    tl;dr: var does not declare local variables, var declares variables local. Use var only if you really want a local variable.



  • @fatbull said:

    tl;dr: var does not declare local variables, var declares variables local. Use var only if you really want a local variable.

    Yeah, I think you're getting at the issue.

    The more I think about it, Google's recommendation probably assumes you're putting the code inside a function, which is why it works (for them) in all browsers at all times... the local _gaq, defined with "var" remains separate from the window's _gaq for the duration of the function. So the Google Analytics team probably isn't as incompetent as I imagine, although changing that line of code to my version could save this headache from happening to another client in the future.

    I wager if I recommended to them to fix their code with:

    <script>
    function DoStuff()
    {
      var _gaq = _gaq || []];
    
      // insert GA code here 
    }
    
    DoStuff();
    </script>

    it would have worked fine as well. But, again, that's more characters than my recommended fix.



  • My point is that this

    @blakeyrat said:

    <script>
    function DoStuff()
    {
      var _gaq = _gaq || []];
    

    // insert GA code here
    }

    DoStuff();
    </script>

    is basically equivalent to that

    <script>
    function DoStuff()
    {
    var _gaq = []];

    // insert GA code here
    }

    DoStuff();
    </script>

    var is “harmless” outside a function because global and local variables are practically the same in this context. But inside a function, var ensures all references to a variable are local, even if a global (or non-local) variable of the same name already exists.

    The important part of your fix was most likely the removal of the var keyword, not the rewrite of || into if. I guess the “recommended” code was simply included in the wrong place where it didn't work.



  • @fatbull said:

    The important part of your fix was most likely the removal of the var keyword, not the rewrite of || into if. I guess the “recommended” code was simply included in the wrong place where it didn't work.

    Hm yes, but that can't be the only problem because the client's code was running in the global scope. Unless <script> tags contain an implicit {}.



  • @tdb said:

    what's wrong with those? The first one uses an unary plus operator (which is a no-op), and parses as 5+(+5). Second one is 5-(-5), etc.

    There's nothing wrong with them; they are just "unnatural" if you're used to writing lots of equations by hand. When writing by hand, I don't know anyone that puts two operators side-by-side as opposed to using parentheses. Of course I admit that might be dependent on the particular math culture in which one is raised; I happen to be in one that doesn't use unary signs without parentheses (except for a single value where it is natural).

    Part of the Excel problem is the single element:

    = -5^2

    Traditional math rules say the result should be -25 (exponentiation before multiplication, which is what unary signs do), but Excel treats that as (-5)^2 so gives you 25.



  • @too_many_usernames said:

    @tdb said:
    what's wrong with those? The first one uses an unary plus operator (which is a no-op), and parses as 5+(+5). Second one is 5-(-5), etc.

    There's nothing wrong with them; they are just "unnatural" if you're used to writing lots of equations by hand. When writing by hand, I don't know anyone that puts two operators side-by-side as opposed to using parentheses. Of course I admit that might be dependent on the particular math culture in which one is raised; I happen to be in one that doesn't use unary signs without parentheses (except for a single value where it is natural).

    Part of the Excel problem is the single element:

    = -5^2

    Traditional math rules say the result should be -25 (exponentiation before multiplication, which is what unary signs do), but Excel treats that as (-5)^2 so gives you 25.

     

     And then there was APL, where a regular minus sign was an operator that could be either binary (X-Y) or unary (-X).  For a negative constant, there was a different character that indicated "negative", a minus sign raised above the center line: -5.

     Technically the value of -5 was the same as the value of -5, but the former was a numeric literal and the latter was an expression.  Also, since APL was all about using vectors and matrices with the standard operators, you could screw up royally by assigning a vector the value 6 5 -4 1 instead of 6 5 -4 1; the former evaluated to the 2-element vector 2 4.



  • @blakeyrat said:

    Unless <script> tags contain an implicit {}.
    No block scopes in JS. Only function scopes.



  • @PSWorx said:

    Yeah, Google is also notorious for that. For some reason they love to write 

    condition && (action1, action2, action3);

    Instead of

    if (condition) {action1; action2; action3}; 

    in various of their libraries. In order to ...  save two bytes? Look cool? I have no idea.

    I have done that (in C) so that I can put actions inside the condition of an if statement (the "action3" here will generally be some other kind of condition, and then joined with a lot more AND and OR operations, and macros...).

    I have also used the bitwise XOR operator for booleans in C, but mostly with the ^= assignment operator (sometimes inside of an expression).

    However, both of these things are rarely needed. In most cases I never need these to use these kind of things. Three-stars (or more) pointers are also rarely needed.

    No block scopes in JS. Only function scopes.

    In Mozilla you can use the let command to make block scopes.



  • @too_many_usernames said:

    Part of the Excel problem is the single element:

    = -5^2

    Traditional math rules say the result should be -25 (exponentiation before multiplication, which is what unary signs do), but Excel treats that as (-5)^2 so gives you 25.

    I disagree.  -5 is a number, not a separate expression.  Unary signs don't "do multiplication", they're part of the number (unless it's a variable, obviously). -(4*5) is not the same as -4*5, just like it's not the same as 4*-5, although the result is the same in this case.  -(5^2) is different than (-5)^2

    In fact, I find your statement really odd.  What is the result of the expression "-5"?  If it's a "unary operation" on 5, then what's the result?  It's a number.



  • @toshir0 said:

    @blakeyrat said:

    Unless <script> tags contain an implicit {}.
    No block scopes in JS. Only function scopes.

    What about doing:

    with( this ){ var blah1 = 1 };
    
    alert( blah1 );

    ... oh shit, it alerts 1. Ok, nevermind.



  • @blakeyrat said:

    @toshir0 said:

    @blakeyrat said:

    Unless <script> tags contain an implicit {}.
    No block scopes in JS. Only function scopes.

    What about doing:

    with( this ){ var blah1 = 1 };
    
    alert( blah1 );

    ... oh shit, it alerts 1. Ok, nevermind.

    Someone on StackOverflow suggests this:

     

    with( {blah1: 1} ){
        alert( blah1 );
    };
    

    alert( blah1 );

     



  • @Zecc said:

    with( {blah1: 1} ){ alert( blah1 ); };

    alert( blah1 );

     

    Wow.



  • @dhromed said:

    @Zecc said:

    with( {blah1: 1} ){ alert( blah1 ); };

    alert( blah1 );

     

    Wow.

    Yeah, it was a real eye-opener for me too. But apparently with is deprecated. I won't miss it.

     



  • @Sutherlands said:

    In fact, I find your statement really odd.  What is the result of the expression "-5"?  If it's a "unary operation" on 5, then what's the result?  It's a number.

    As I said originally, I think it's a matter of personal style and the way I perceive notational consistency. It bothers me that in Excel

    =-5^2

    has a different result than

    =0-5^2

    When basic arithmetic says they should be the same thing. I know that it has to do with the way Excel parses expressions, but I find it annoying.



  • @too_many_usernames said:

    @Sutherlands said:
    In fact, I find your statement really odd.  What is the result of the expression "-5"?  If it's a "unary operation" on 5, then what's the result?  It's a number.

    As I said originally, I think it's a matter of personal style and the way I perceive notational consistency. It bothers me that in Excel

    =-5^2

    has a different result than

    =0-5^2

    When basic arithmetic says they should be the same thing. I know that it has to do with the way Excel parses expressions, but I find it annoying.

     

    Your "reasoning" is completely WRONG. If that were true, then you would get the same result for:

     =2-7^2

    And clearly that is something complely different [-47]

    NEGATION is not the same as SUBTRACTION. And Negation of an expression is NOT that same as a negative number. A negative number is JUST a number there are NO "operators" conceptually involved.

     


  • ♿ (Parody)

    @too_many_usernames said:

    As I said originally, I think it's a matter of personal style and the way I perceive notational consistency. It bothers me that in Excel

    =-5^2

    has a different result than

    =0-5^2

    When basic arithmetic says they should be the same thing.

    No, it doesn't say that at all. Ambiguity in how we parse expressions (either in our heads or our software) is not the same as "basic arithmetic." Really, as was pointed out to you, this is just a problem with using the same symbol for the subtraction operator and to express a negative number.


  •  @too_many_usernames said:

    As I said originally, I think it's a matter of personal style and the way I perceive notational consistency. It bothers me that in Excel

    =-5^2

    has a different result than

    =0-5^2

    When basic arithmetic says they should be the same thing. I know that it has to do with the way Excel parses expressions, but I find it annoying.

    Just like

    = (-5)^2

    has a different result than

     =0(-5)^2

     The last one is a syntax error, one that has been anoying me since the first time i used excell,since this obviouse should translate to 0*(-5)^2 using common math rules. At least excell 2007 corrects this exmample correctly.



  • @Zecc said:

    @dhromed said:

    @Zecc said:

    with( {blah1: 1} ){ alert( blah1 ); };

    alert( blah1 );

     

    Wow.

    Yeah, it was a real eye-opener for me too. But apparently with is deprecated. I won't miss it.
    But don't worry. You gotta love "function wrapping"

    (function() {
       doStuff();
    })(args);

     



  • @toshir0 said:

    You gotta love "function wrapping"

    (function() {
       doStuff();
    })(args);
     

     

    This is, in fact, an awesome feature of javascript.

     


  • ♿ (Parody)

    @dhromed said:

    @toshir0 said:
    You gotta love "function wrapping"

    (function() {
       doStuff();
    })(args);
    This is, in fact, an awesome feature of javascript.
    I don't love it (yet). What does that do?


  • @boomzilla said:

    No, it doesn't say that at all. Ambiguity in how we parse expressions (either in our heads or our software) is not the same as "basic arithmetic." Really, as was pointed out to you, this is just a problem with using the same symbol for the subtraction operator and to express a negative number.
     

    Fair enough, I should have said "Arithmetic that I'm used to" instead of "basic arithmetic."  I agree that it is a difference in parsing, no more, no less.

     @TheCPUWizard said:

    Your "reasoning" is completely WRONG. If that were true, then you would get the same result for:

     =2-7^2

    And clearly that is something complely different [-47]

    I'm not sure what you mean here. Excel says

    =2-7^2 --> -47

    =-7^2 +2 --> 51

    As a human, I'd expect those to evaluate to the same thing, because (as has been said many times) I do not overload the sign and subtraction operator the way that Excel does.  It's not *wrong* it's just *different* and it annoys me because it requires a different parsing method depending on the location of substring "-7^2".

    NEGATION is not the same as SUBTRACTION

    I'm not sure what you mean.  Negation of a number can be defined by the equation

    -x = 0-x

    which is inherently subtraction (it's also inherently multiplication by negative one).



  • @boomzilla said:

    @dhromed said:
    @toshir0 said:
    But don't worry. You gotta love "function wrapping"
    (function() {
       doStuff();
    })(args);
    This is, in fact, an awesome feature of javascript.
    I don't love it (yet). What does that do?
    I'm not worried. I use IIFEs all the time*.

    I usually write it like this though:

     

    
    var Module = {};
    (function(Module){
        // Set stuff into Module..
    }).call(Module, Module);
    

     

    For those of you not following, what this does (inline) is apply an anonymous function to an object, Module, which will be 'this' inside the anonymous function. While we're at it, the same object is also passed as the first argument to the function, so it can also be known as "Module" inside it.

    *For sufficiently small amounts of "all the time".



  • @too_many_usernames said:

    I'm not sure what you mean.  Negation of a number can be defined by the equation..

     There is a difference between being able to define one thing in terms of a different thing, and those two things being the *same*

     Consider for centuries there were societies that did not have the concept of negative numbers, but they could (and did) subtract one quantity from another; it was simply considered "impossible" to subtract a larger quantity from a smaller.

     My original point was the if  

        -5^2   and  0-5^2 where believed to be the same, then 2-7^2 would by identical also since:

     0-5 = -5
     2-7 = -5

    If you can not do the second substition (obviously you cant), then you can not do the first either.

     


Log in to reply