Results 1 to 9 of 9

Thread: [MISC] Why do inc/deinc operators not work after arrays

  1. #1
    Join Date
    Mar 2011
    Posts
    1,851
    Thanks
    59
    Thanked 104 Times in 102 Posts
    Blog Entries
    4

    Default [MISC] Why do inc/deinc operators not work after arrays

    Was fiddling around with some JS arrays today -

    Code:
    <script type="text/javascript">
    var counter = 0;
    function pLog(arg) {
    	console.log(++counter + ": " + typeof(arg) + "(" + arg + ")");
    }
    
    pLog(["1"][0]); 	//string(1)
    pLog(++["1"][0]);	//number(2)
    pLog(--["1"][0]);	//number(0)
    
    pLog(["1"][0]--); 	//number(1)
    pLog(["1"][0]++);	//number(1)
    </script>
    Why do the inc/deinc operators cast the value to a number but not change it when they're placed after the array?

  2. #2
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    30,495
    Thanks
    82
    Thanked 3,449 Times in 3,410 Posts
    Blog Entries
    12

    Default

    I'm not 100% sure, but that's a pretty bizarre looking construct to me. And, if you put any real value in the second array, you will get NaN, undefined, or an error. I guess what's happening is type conversion, but only when the script parser can, in it's own odd way, make sense of the input. You're not adding, comparing, or concatting anything after the first array. And it's only because [0] apparently evaluates to nothing (not even as zero, null, an empty string, or false), and processing apparently stops there (actually just before there), that you're not having some kind of error. Hmm, odder than that because [0] appears to evaluate sometimes like a space would, and other times sort of as a semi-colon. Not really, because in that context a semi-colon would be a syntax violation, but in the sense of a sort of terminus.

    Is there anywhere in javascript where [1][0] really means anything if it's not being used as the lookup for a named or otherwise defined multidimensional array for which it is a suffix?

    Maybe it does, but I might have been absent that day.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  3. #3
    Join Date
    Mar 2011
    Posts
    1,851
    Thanks
    59
    Thanked 104 Times in 102 Posts
    Blog Entries
    4

    Default

    Quote Originally Posted by jscheuer1 View Post
    I'm not 100% sure, but that's a pretty bizarre looking construct to me. And, if you put any real value in the second array, you will get NaN, undefined, or an error. I guess what's happening is type conversion, but only when the script parser can, in it's own odd way, make sense of the input. You're not adding, comparing, or concatting anything after the first array. And it's only because [0] apparently evaluates to nothing (not even as zero, null, an empty string, or false), and processing apparently stops there (actually just before there), that you're not having some kind of error. Hmm, odder than that because [0] appears to evaluate sometimes like a space would, and other times sort of as a semi-colon. Not really, because in that context a semi-colon would be a syntax violation, but in the sense of a sort of terminus.

    Is there anywhere in javascript where [1][0] really means anything if it's not being used as the lookup for a named or otherwise defined multidimensional array for which it is a suffix?

    Maybe it does, but I might have been absent that day.
    As far as I understand it the [0] dosen't evaluate to nothing. Its an index for the array before it and it and so it returns the first element of the array (in this case "1")
    Last edited by keyboard; 01-22-2017 at 08:53 AM. Reason: that code was stupid

  4. #4
    Join Date
    Mar 2011
    Posts
    1,851
    Thanks
    59
    Thanked 104 Times in 102 Posts
    Blog Entries
    4

    Default

    Quote Originally Posted by keyboard View Post
    Was fiddling around with some JS arrays today -

    Code:
    <script type="text/javascript">
    var counter = 0;
    function pLog(arg) {
    	console.log(++counter + ": " + typeof(arg) + "(" + arg + ")");
    }
    
    pLog(["1"][0]); 	//string(1)
    pLog(++["1"][0]);	//number(2)
    pLog(--["1"][0]);	//number(0)
    
    pLog(["1"][0]--); 	//number(1)
    pLog(["1"][0]++);	//number(1)
    </script>
    Why do the inc/deinc operators cast the value to a number but not change it when they're placed after the array?
    Figured it out.
    The last two perform the incrementations after its been logged, but for some reason they still cast as it as a number.

  5. #5
    Join Date
    Nov 2014
    Location
    On A Scottish Island
    Posts
    488
    Thanks
    0
    Thanked 62 Times in 58 Posts

    Default

    JavaScript arrays must have an array-name identifier, see here.

    The function call pLog(["1"][0]); is not passing an array-name identifier to the function "pLog();" and will produce unpredictable results.

  6. #6
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    30,495
    Thanks
    82
    Thanked 3,449 Times in 3,410 Posts
    Blog Entries
    12

    Default

    I get it now. When you post inc or post dec anything, it's value is evaluated as whatever it is in the current expression, it is however (if possible/necessary - as required for the operation*) type converted to a number. The next time you try to access the value it will have been inc'ed or dec'ed.


    *which is evaluating it's current value (before adding or subtracting to/from it) as a number.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  7. #7
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    30,495
    Thanks
    82
    Thanked 3,449 Times in 3,410 Posts
    Blog Entries
    12

    Default

    Another way of looking at it (same way actually) - consider:

    Code:
    a = "1"
    pLog(a++) // number(1)
    pLog(a) // number(2)
    Now be aware that at the beginning a is === to ["1"][0]* and ++ is a mathematical operator. That type converts "1" to a number. But the meaning of the post ++ operator is that in the current expression, the current value is used.


    *from the console:

    Code:
    a = "1"
    "1"
    a === ["1"][0]
    true
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  8. #8
    Join Date
    Mar 2011
    Posts
    1,851
    Thanks
    59
    Thanked 104 Times in 102 Posts
    Blog Entries
    4

    Default

    Quote Originally Posted by styxlawyer View Post
    JavaScript arrays must have an array-name identifier, see here.

    The function call pLog(["1"][0]); is not passing an array-name identifier to the function "pLog();" and will produce unpredictable results.
    They don't need a name as far as I'm aware.
    You can pass them directly to functions and they'll behave as expected.

    Code:
    function test(arg) {
    	return arg.length;
    }
    
    test(["val1", "val2", "val3", "val4"]);
    Same works with any type of variable (functions, objects, etc.)

    Quote Originally Posted by jscheuer1 View Post
    I get it now. When you post inc or post dec anything, it's value is evaluated as whatever it is in the current expression, it is however (if possible/necessary - as required for the operation*) type converted to a number. The next time you try to access the value it will have been inc'ed or dec'ed.


    *which is evaluating it's current value (before adding or subtracting to/from it) as a number.
    I find it interesting that in the post-inc it converts it to a number, but doesn't actually modify its value until after the expression.



    Sorry for the weird array and stuff (["1"][0]).
    That was to do with the other code I was writing at the time (from my latest blog post).

    Added a bit more confusion to this question than needed haha.

  9. #9
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    30,495
    Thanks
    82
    Thanked 3,449 Times in 3,410 Posts
    Blog Entries
    12

    Default

    I agree it's odd, but if you think about it, the post inc and post dec, since they are numeric operators, must convert to numeric (if possible when the value isn't already numeric) in order to present the current value as is the initial part of what they do. No numeric operator can return a string other than one which represents an error, even that's rare if it ever happens. I believe even NaN is cot considered a string, nor is undefined, unless it's quoted.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

Similar Threads

  1. At A Glance Conditionals: Ternary Operators
    By rainarts in forum JavaScript
    Replies: 3
    Last Post: 07-26-2008, 04:45 AM
  2. Replies: 4
    Last Post: 05-06-2007, 09:00 PM
  3. Operators and "dots"
    By pcbrainbuster in forum PHP
    Replies: 14
    Last Post: 03-07-2007, 08:38 PM
  4. Dynamic operators in if conditionals
    By Aphex_ in forum PHP
    Replies: 5
    Last Post: 05-17-2006, 06:53 AM
  5. Arrays
    By InNeedofHelp in forum JavaScript
    Replies: 5
    Last Post: 02-27-2006, 09:40 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •