Le 13/03/2011 10:57, Claus Reinke a écrit :
>>>>> The little "issue" I see in returning 1) index properties in
>>>>> ascending
>>>>> order 2) all other properties in addition order is that there is a
>>>>> bit
>>>>> of information lost in the process: overall property addition order
>>>>> (index properties included).
> ..
>> Music album in which one title is a number. I lose the opportunity to
>> store the album as a dictionary indexed on titles and sorted the order I
>> have inserted the keys in. I would be forced to use an array. This is
>> where the notion of dictionary finds some limitation.
>
> Please note that this use case highlights the highjacking of numeric
> Strings as indices, not the lack of overall property addition order
> including indices.
>
> 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. This would avoid the gaps in the String keys
> highlighted by your use case, but you would still not get a full
> record of insertion order. Doing that might make insertion
> ordering slightly more palatable, though.
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]
-----------
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.David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
