Le 12/03/2011 09:06, Brendan Eich a écrit :
> On Mar 11, 2011, at 12:49 PM, Charles Kendrick wrote:
>
>> Yes Allen, hence the urgency.  If IE9 final ships that way, the
>> "goose is cooked":
>
> I hear tell of something happening next Monday. Goose, well-done,
> stuffed, I think.
>
>
>> 1. we will have a new de facto standard iteration order for Object
>> that does not match any known use case - it is purely an
>> implementation detail leaking through
>
> IE9 seems to match
> the http://wiki.ecmascript.org/doku.php?id=strawman:enumeration strawman.
>
>> 2. the majority of real-world applications will be slowed down
>> because developers will need to re-implement the very commonly needed
>> LinkedHashMap behavior in JavaScript
>
> Where is this LinkedHashMap thing from? Oh, Java.
>
> Again, IE9 is late to the party in breaking insertion order for
> indexed properties.
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).

In ECMAScript 5 (+# notation), if I want all index properties of an
object o in ascending order, I can do something along the lines of:
Object.getPropertyNames(o)
    .filter(#(e){ e.match(/[1-9]\d+/) }) // remove non-number strings
    .sort(#(a,b){ Number(a) < Number(b) ?1:-1 });   // sort in ascending
numeric order
My point is that I do not need the ES engine to provide this. I can get
it myself.
However, only the engine can know the information of the overall
insertion order (if I have inserted the "2" property before the "1" for
instance).

What is the rational or use case behind having index properties at first
for objects and then the rest of properties?

David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to