If harmony would introduce this syntax "guarded" under a new script type, there would at least be no danger of breaking the web (existing scripts).
However, negative "array indexes" might cause confusion when doing so implicitly. If you asume array indexes are "just" properties it'll be hard to debug a snippet like `while (x = arr[--i]) ...` (not my own example). While it wouldn't be my preferred way of doing this, it's still valid and will cause very obscure and hard to debug problems. I guess I would like -n to map to length-n, but I'm not sure whether it's worth the cost described above. After all, it's just sugar. - peter > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@mozilla.org] On Behalf Of Dmitry A. Soshnikov > .. > >> 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()`? >> > Object.keys and Object.getOwnProertyNames are both precisely > defined by ES5. keys returns the names of all non-enumerable own > properties of an object. getOwnPropertyNames returns the names of > all own properties. > > For example look at the results of Object.keys(new String('abc')) > and Object.getOwnPropertyNames(new String('abc')) on an ES5 > conforming implementation. > > .. >> Still ES has concept of an "array index" (separating it from all >> other properties), I think a "virtual array index" is also good. >> > Not really. ES5 does not generally consider array elements or > "array index" property names as separate or different from other > properties or property names. According to the ES5 spec. (15.4) > "array index" is a term used to talk about property names that > conform to a specific requirement (ToString(ToUint32(name) ) === > name and ToUint32(name) !==2^32-1). > > Instances of the Array constructor has special semantics for > defining and updating "array index" properties. In addition, some > of Array.prototype functions that perform arithmetic on "array > index" property names do it in a manner that ensures results are > also "array index" names. Other than that ES5 doesn't define any > special semantics for "array index" properties. Implementations > are free to optimize how they store array index properties (and > many implementations do) but they are also free to optimize the > storage of any property as long as the optimization maintains the > observable ES5 semantics. > > [from a different message] >> ES5 brought special semantics for subscription of strings, i.e. >> "abc"[0] is "a", maybe it worth to make another sugar for arrays >> too? > Actually, all that ES5 did was specify that String objects (not > string values) have non-writable, non-configurable properties > corresponding to the individual characters of the encapsulated > string value. "abc"[0] is really equivalent to (new > String("abc"))[0] > >> Btw, if yes, it will touch strings too. > Presumably, any object with a 'length' property. > > As Oliver said, this would break any code that currently uses > property names like "-1". This isn't just syntactic sugar. It also > has all sorts of complications relating to the basic property > access semantics. Getting this right would probably require a > major redesign of ECMAScript object/property semantics in a manner > that I wouldn't anticipate happening anytime soon. > > Allen > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
