[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?

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. ;)

Quote:

---

Originally Posted by jscheuer1

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")

Quote:

---

Originally Posted by keyboard

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.

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.

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.

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

---

Quote:

---

Originally Posted by styxlawyer

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

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.

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.