iteration order for Object

[Claus Reinke]

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