Negative indices for arrays

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Thu Nov 11 11:51:15 PST 2010


On 11.11.2010 22:39, Oliver Hunt wrote:
>
> On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:
>
>> OTOH, negative indices, are even not array indices. I.e.
>>
>> var a = [1,2];
>> a[-1] = 0;
>> print(a); // 1,2
>> print(a.length); // 2
>>
>> From this viewpoint -- for what are they? Seems again, `-n` notations 
>> for arrays and strings is useful as a "from the end"-sugar. So now I 
>> may propose it.
>
> They're property names,

Thanks, I perfectly know what are they. And said myself that there is an 
"issue" that there's no stratification of properties/methods (by dot 
notation) and hash keys/array indexes (by square bracket notation). But 
it doesn't change fact that ES spec has concept of an "array index" -- a 
property name which is ToString(ToUInt32(name)) === name. Now I propose 
also a virtual array index which is ToString(ToInt32(name)) === name.

> what you're suggesting would be a fairly dramatic change in behaviour 
> and I would be concerned about it causing site breakages.
>

No any dramatic changes. ES5 standardized strings indices. Caused it 
dramatic changes? Nope. And this sugar (which is available in many 
langs) also won't I think.

> I can easily imagine code that did:
> var someArray = ..;
> var i = someArray.length;
> while(v = someArray[--i]) { .. do something... }
>

Didn't I show the same code in the previous message? Yeah, we discussed 
it on Twitter.

> Which would now be wrong.
>

And concluded that this is a feature, not a bug. Both, Python and Ruby 
have the same behavior for such a `while` case. So what? It doesn't 
change the fact that this is still a useful sugar.

> Likewise bugs that lead to code doing a[-1]=foo; would change from 
> being "safe" to modifying the content of the actual array values.
>

In `-n` virtual property semantics it will modify array value -- 
starting from the end.

> I'm sure I've had this discussion before, the fundamental problem is 
> that ES does not really distinguish between dot and bracket property 
> access, whereas afaik python does (i don't know about ruby).
>

Yes, I mentioned it myself several times (in articles and including 
several topics in es-discuss). Yes, Python distinguish. Ruby too. But 
from your position, ES already has some lacks then. E.g. Object.keys() 
-- what does it mean? What kind of "keys" you have found here? Or maybe 
`Object.getOwnPropertyNames()` ?

Still ES has concept of an "array index" (separating it from all other 
properties), I think a "virtual array index" is also good.

Dmitry.

> --Oliver
>
>>
>> On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
>>> Actually, I'm still not sure myself whether I want this semantics in 
>>> JS for arrays. I remember one case (some simple math task) when I 
>>> was needed a[-1] and was glad that JS supports it -- I used `for 
>>> (var i = -2; i < 10; i++) a[i]`, and it was very elegant decision at 
>>> that moment.
>>>
>>> There is also one lack (?) with decreasing counter loop (brought in 
>>> discussion on Twitter), e.g.:
>>>
>>> var a = [1, 2, 3], i = a.length;
>>>
>>> while (v = a[--i]) {
>>>   print(i, v)
>>> }
>>>
>>> that brings: 2,3  1,2  0,1  -1,3  -2,2  -3,1
>>>
>>> i.e. double enumeration with this semantics. But formally, it's not 
>>> a bug, but a feature -- both Python and Ruby have the same semantics 
>>> in such a `while` case.
>>>
>>> Another reason I'm still no sure about a[-1] is that JS (in contrast 
>>> with the same Python and Ruby) has no stratification of normal 
>>> properties -- via dot notation, and subscription properties -- via 
>>> square bracket notation. I mentioned this in previous mentioned 
>>> thread. And from this viewpoint, probably it's not good that o[-1] 
>>> means exactly "-1" and a[-1] means a[`last`]. Don't know.
>>>
>>> Want both -- and (probably sometimes needed) "-1", and sugar for 
>>> [`last`].
>>>
>>> Though, repeat, since ES5 brought special semantics for subscription 
>>> of strings, i.e. "abc"[0] is "a", maybe it worth to make another 
>>> sugar for arrays too? Btw, if yes, it will touch strings too.
>>>
>>> Dmitry.
>>>
>>> On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
>>>> Hello,
>>>>
>>>> How likely (based on backward compats) that Harmony will support 
>>>> Pythonic negative indices for arrays? Ruby supports them too. There 
>>>> was previous indirect mention, were Brendan agreed that Harmony 
>>>> needs such a semantics for arrays, however, that discussion wasn't 
>>>> formed to something concrete.
>>>>
>>>> Recently, there was the same discussion in CoffeeScript's tracker 
>>>> -- https://github.com/jashkenas/coffee-script/issues#issue/827 . 
>>>> Since Coffee uses JavaScript as its lower level, there were 
>>>> proposals to provide an alternative syntax for this (e.g. a[* - 1], 
>>>> where * means a.length, allowing this feature to be generic), 
>>>> though, I'm not sure this exact syntax is needed for ES. However, I 
>>>> mentioned there, that if Harmony itself will support this feature 
>>>> in Python's/Ruby's semantics, then Coffee won't need an alternative 
>>>> thing.
>>>>
>>>> Currently, this feature may be easily implemented using proxies: 
>>>> https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js 
>>>> (example), 
>>>> https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js 
>>>> (implementation), however possibly it's good to have this semantics 
>>>> for objects with [[Class]] "Array" as native. I think it's 
>>>> acceptable, since we already have such alternative semantics for 
>>>> String objects.
>>>>
>>>> Toughs?
>>>>
>>>> Dmitry.
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101111/42465792/attachment.html>


More information about the es-discuss mailing list