On Mar 10, 2011, at 6:50 PM, Charles Kendrick wrote:
> Let's ignore, for the moment, the fact that the underlying implementation of
> Object and Array is very similar.
Not true in all modern optimizing VMs.
> Has a use case been identified where treating numeric properties differently
> from other properties is a desirable behavior?
Yes. Users occasionally create arrays empty and insert elements in
reverse-index or other order. Then for-in discloses the insertion order if the
array is deoptimized to be like an object, or else enumerates in index order if
the array manages to be optimized.
Implementations are allowed to leak their optimization strategies via for-in,
by explicit language in ES1-5.
So users complain, and almost always want for-in over an array to use index
order.
If I'm reading you right, you don't mind us specifying arrays enumerating
indexed "own" properties first and in index order.
But it gets worse: several notable JS libraries, including IIRC jQuery (the #1
library in popularity right now), use indexed properties on Object instances --
frequently. I'll try to dig up the references.
Those VMs that optimize indexed properties on Object to be (a) fast; (b, and
therefore) enumerated in index order, do better on such code. VMs that optimize
only for certain "dense-enough arrays" lose.
This creates pressure to follow the performance leader and treat indexed
properties the same, in terms of enumeration, on all objects including arrays.
> Is there any programming language or library for any programming language
> where this behavior has been intentionally implemented as a collection class?
Not really relevant based on the pressures in the ecosystem at hand.
> In my limited experience both are "no".
>
> Harmony is a clean break: seems like a great opportunity to implement the
> behavior for Object for..in iteration that is most useful.
Harmony is *not* a clean break. I don't know why you wrote that.
Harmony has some room to break compatibility, especially if the old forms are
caught by early errors. I've spoken of one hand's worth of fingers to count
these breaks (the "five fingers of fate"). The valuable and opposable thumb is
for removing the global object from the scope chain. The index finger on my
hand is paren-free relaxation of syntax combined with better for-in semantics.
The middle finger may as well go for typeof null == "null" (which can't be
caught by any early error in a practical implementation; testing and static
analysis tools needed). And so on, but for only two more fingers (on my hand;
others on TC39 may differ on particulars, and we all may have another hand
behind our back with back-up candidates).
Harmony is *not* "anything goes", VB7 ("Visual Fred"), Cobol2000, or even Perl
6 vs. 5 (I'm not saying anything bad about Perl 6 here -- I like that it makes
many and large changes based on lessons learned). Harmony must be mostly
compatible with JS as it is today so that code can migrate forward.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
