iteration order for Object
Claus Reinke
claus.reinke at talk21.com
Mon Mar 14 09:40:05 PDT 2011
>> 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
More information about the es-discuss
mailing list