A spec workaround would be to stop converting numeric keys to
Strings, ie, 1 and '1' would be different keys. Then number keys
could behave as Array indices, while String keys would behave
as other properties.
Interesting idea, but I think it would be to big of a break from ES5,
ES in general and JS in reality.
-----------
o = {};
o['1'] = 16;
Object.getOwnPropertyNames(o); // ['1']
o[1] = 12;
Object.getOwnPropertyNames(o); // ['1'] and not ['1', 1]
-----------
Well, 1 wouldn't be a "name", it would be an "index", right?
So there'd be an Object.getOwnPropertyIndices(o), returning [1].
And there'd be the Array interface with further index operations.
You would also break the invariant o[1] === o['1'] which may be used a
lot when people retrieve numbers from <input> fields. In my opinion,
property name string conversion seems to be too deeply anchored in the
language and usages to be questioned now.
Breaking that invariant would be the core of the change.
It wouldn't be a minor change (one would need to make
decisions and work out the consequences), and I mainly
raised the idea to provide a different viewpoint.
Often in language design, thinking through a non-standard
idea can help to elucidate other aspects of the problem,
even if the idea itself might turn out to be unimplementable.
And occasionally, an unlikely idea turns out to lead to a
consistent and desirable changeset.
Some aspects I'd like to highlight:
1 currently, _every_ Object has "numeric" indices (via conversion),
so Array is really just a mixin that provides more operations
for working with those indices (using indices without Array is
arguments-is-not-an-Array all over again)
2 if the enumeration strawman gets accepted (and in current
practice anyway), those numeric indices get stolen from
the property names (without the enumeration spec, the
theft isn't noticable according to ES5, at least not so directly?)
3 separating numeric indices from property names would
acknowledge 1 while lessening the impact of the enumeration
strawman, solving 2; it comes with its own consequences
that would need careful checking, but not separating indices
from names will not make 1 or 2 go away
4 separating indices from names would also open the possibility
of making indices available _only_ in Arrays, so Array would
become a proper sub-"class" rather than a mixin, solving 1
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
