iteration order for Object

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

iteration order for Object

Charles Kendrick-2
I believe it is very very important that the ECMAScript standard specify that when a new Object
is created, for..in iteration traverses properties in the order they are added, regardless of
whether the properties are numeric or not.

The primary reason is that I think it makes ECMAScript a much more expressive and usable
language, and results in better performance in real-world applications.

Secondarily, the fact that the Chrome browser has deviated from this de-facto standard is
creating a small crisis for site owners and web application developers, and it will get much
much worse if any other browser vendors follow suit.

This seems to have been most recently discussed in 2009 with inconclusive results.

        https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html

I have summarized the argument for this feature below - this argument has swayed others who
were initially opposed.

I'm hoping we can get quick consensus that *specifically Object iteration order* should be
preserved, without getting too bogged down in the details of specifying exactly what happens
for Arrays, prototype chains, etc.  Major stakeholder agreement on this one aspect should be
enough to prevent any other vendors from shipping browsers that break sites, and get the Chrome
bug for this re-instated.


== Expressiveness and Performance argument

A very common use case where order preservation is desirable is providing the set of options
for a drop-down list in JavaScript.  Essentially all Ajax widget kits have such an API, and
usage is generally:

    selectControl.setOptions({
       storedValue1 : "displayValue1",
       storedValue2 : "displayValue2",
       storedValue3 : "displayValue3"
    })

Here are some examples of what alternatives might look like - all of them are far, far worse:

#1 Parallel arrays:

    selectControl.setOptions(
       ["storedValue1",
        "storedValue2",
        "storedValue3"],
       ["displayValue1",
        "displayValue2",
        "displayValue3"]
    })

- this is awkward and unnatural, and doesn't correspond to how a list of options is specified
   in HTML

- involves *double* the number of allocations / GC-tracked objects (6 strings and 2 Arrays
   vs one Object and 3 Strings - slots don't GC)

- replacing a key/value pair requires a linear (0(n)) search unless secondary indexing
   approaches are used, which requires yet more allocation both to build and maintain the index,
   as well as a level of sophistication not typical for a scripting language user


#2 Array of Objects

     selectControl.setOptions([
         {value: "storedValue1", text: "displayValue1"},
         {value: "storedValue2", text: "displayValue2"},
         {value: "storedValue3", text: "displayValue3"}
     ]);

- verbose and redundant code - reiterates "value" and "text" once per entry

- much worse Object allocation than #1 (which was already bad): one Object + 2 Strings per
   property

- same linear search / extra allocation / developer sophistication issue as #1



#3 Array of Arrays

     selectControl.setOptions([
         ["storedValue1", "displayValue1"],
         ["storedValue2", "displayValue2"],
         ["storedValue3", "displayValue3"]
     ]);

- verbose, finger-spraining punctuation density

- much worse Object allocation than #1 (which was already bad): one Array + 2 Strings per
   property

- same linear search / extra allocation / developer sophistication issue as #1




In a nutshell, dropping order preservation results in:

1. less expressive code

2. more bytes on the wire (both in code-as-such and JSON)

3. degraded application performance via increased allocations and the overhead of implementing
    order-preserving behavior in JavaScript


== Historical behavior argument

All browsers that have ever had non-negligible market share have implemented order-preserving
Objects - until Chrome 6.

Like many universally consistent, obviously beneficial behaviors, many developers relied on it
assuming eventual standardization.

Thousands of sites and applications are broken by Chrome's decision to drop the
order-preserving behavior.  There is a bug against Chrome's V8 engine (currently marked
"WorkingAsIntended"):

       http://code.google.com/p/v8/issues/detail?id=164

People can "star" issues to be notified of changes in status or discussion.  This issue has by
far more stars than the most-starred Feature Request (E4X support), more than double the stars
of the runner-up, and more stars than roughly the top 20 confirmed bugs combined.

And this does not consider all the stars on other versions of this issue that were closed as
duplicates.

Various arguments have gone back and forth on whether Chrome should fix this bug without
waiting for standardization, but not a single person has indicated that they would prefer that
Object does not preserve order.

In a nutshell, there is overwhelming support for adding this behavior to the standard, and
still time to avoid all the wasted effort of changing all these sites and applications.  Very
few non-order-preserving browsers exist in wild, and the behavior is limited to browsers that
are updated very frequently or even automatically.


== Objections and counter-arguments

1. Array for..in iteration order has always been inconsistent across browsers

Yes, this is true.  I am proposing only that Object preserves insertion order, not Array.

No developers or sites rely on Array for..in iteration order, since it was never consistent.

If Array for..in iteration continues to be unordered, any developer that cares about the tiny
performance difference can use an Array to store non-numeric property/value pairs.


2. Not preserving insertion order allows JavaScript to run faster

It can't be a very large optimization, since Safari and Firefox continue to challenge Chrome's
performance while maintaining in-order iteration.  And if it's only a small optimization, then
obviously it's completely dwarfed by the application-level penalties incurred re-implementing
this key behavior in JavaScript.


3. It's good enough to preserve order for non-numeric keys only

This is an abysmal compromise, with the worst traits of each alternative.  It requires browser
vendors to implement order preservation, such that we don't get the minor optimization that's
possible from not preserving order at all.  At the same time, it requires that applications and
frameworks deal with lack of order for numeric keys, which are very common: in the use case of
mapping stored to displayed values, stored values are very often numeric.

It's also just bad design.  It surprising and counter-intuitive that numeric keys are treated
differently from non-numeric.  The reality is that an implementation detail of Array is
bleeding through to Object.




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Jeff Walden-6
Another idea might be to introduce OrderedObject or somesuch with guaranteed enumeration order.  You might lose object literal support (although that could be readded), but that's the only loss that comes to mind after brief thought.

Jeff
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Brendan Eich-3
In reply to this post by Charles Kendrick-2
Please see http://wiki.ecmascript.org/doku.php?id=strawman:enumeration.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Allen Wirfs-Brock
In reply to this post by Charles Kendrick-2

On Mar 10, 2011, at 3:48 PM, Charles Kendrick wrote:

This seems to have been most recently discussed in 2009 with inconclusive results.

https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html


See thread starting at: 
https://mail.mozilla.org/pipermail/es-discuss/2010-December/012459.html


I have summarized the argument for this feature below - this argument has swayed others who were initially opposed.

I'm hoping we can get quick consensus that *specifically Object iteration order* should be preserved, without getting too bogged down in the details of specifying exactly what happens for Arrays, prototype chains, etc.  Major stakeholder agreement on this one aspect should be enough to prevent any other vendors from shipping browsers that break sites, and get the Chrome bug for this re-instated.


But those details are exactly the situations that break interoperability.

In https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html I identified scenarios where you can expect to get interoperable enumeration order among all major objects:
	The object has no inherited enumerable properties
	The object has no array indexed properties
	No properties have been deleted
	No property has had its attributes modified or been changed from a data property to an accessor property or visa versa
The distinction you make between Arrays and Objects isn't one that necessarily exist at the implementation level. Are you suggesting that for all objects other than Array instances that array indexed properties must enumerate in insertion order? Chrome isn't the only browser where that currently isn't true.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
On 3/10/2011 5:03 PM, Allen Wirfs-Brock wrote:
> But those details are exactly the situations that break interoperability.

This behavior was perfectly consistent across all browsers until Chrome 6.  I think it's more
appropriate to say that Chrome is not interoperable with thousands of sites than to define
interoperable behavior based on a minority browser's very very recent break from a de-facto
standard that stood for 15 years.

Further, Chrome is used principally by developers and auto-updates itself.  If Chrome behavior
were reverted today, the number of browsers out there with this behavior would trend to zero in
probably months.

But the sites and applications will last many years.  Just being practical here.

> In https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html I identified
> scenarios where you can expect to get interoperable enumeration order among all major objects:
>
> The object has no inherited enumerable properties
> The object has no array indexed properties
> No properties have been deleted
> No property has had its attributes modified or been changed from a data property to an accessor property or visa versa

Quite correct, but because of your #2, this is worst-of-both options behavior:

---
3. It's good enough to preserve order for non-numeric keys only

This is an abysmal compromise, with the worst traits of each alternative.  It requires
browser vendors to implement order preservation, such that we don't get the minor
optimization that's possible from not preserving order at all.  At the same
time, it requires that applications and frameworks deal with lack of order for numeric
keys, which are very common: in the use case of mapping stored to displayed
values, stored values are very often numeric.
---

> The distinction you make between Arrays and Objects isn't one that necessarily exist at the
> implementation level.

Correct.  You and I know that Objects and Arrays share most of their implementation.  But don't
you agree that, approaching the language as a beginner, it's a surprise that numeric indices
behave differently from other indices *on Object*?

> Are you suggesting that for all objects other than Array instances that
> array indexed properties must enumerate in insertion order? Chrome isn't the only browser where
> that currently isn't true.

No.  I have no opinion on standardized iteration order on Array or on any object other than
Object (Date, Regexp, et al).  There never was any consistency there, and I have never seen a
use case where it could conceivably be important that properties on eg a Regexp have a specific
order.  I think it would probably be best to leave these unstandardized, to give browser
vendors maximum leeway to optimize.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
In reply to this post by Jeff Walden-6
I'd love to have a full set of collections for JavaScript, but just to clarify, adding a
separate OrderedObject wouldn't address most of the issues I've raised:

1. it would be no help to JSON - there would still be the severe expressiveness and object
allocation overhead I previously described

2. it would remain a surprising "gotcha" that numeric indices behave specially on Object

3. it would not address the backcompat issue with all the sites that depend on ordering

On 3/10/2011 5:00 PM, Jeff Walden wrote:
> Another idea might be to introduce OrderedObject or somesuch with guaranteed enumeration order.
> You might lose object literal support (although that could be readded), but that's the only
> loss that comes to mind after brief thought.
>
> Jeff
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Boris Zbarsky
In reply to this post by Charles Kendrick-2
On 3/10/11 8:44 PM, Charles Kendrick wrote:
> It requires
> browser vendors to implement order preservation, such that we don't get
> the minor
> optimization that's possible from not preserving order at all.

For what it's worth, not preserving order for numeric properties allows
optimizations that are decidedly not "minor".

You can compare the performance of "fast" and "slow" arrays in
Spidermonkey to see the difference.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
Yes, great performance enhancements are available for *Arrays* - but this is not relevant
because as I explicitly stated, I am not suggesting anything be clarified or standardized with
respect to for..in order for Arrays.

People use Objects as classes, instances, "associative arrays" / Maps, etc.  Numeric keys are a
tiny minority and there would be no measurable performance gains for special treatment of such
keys *on Object*.

However because frameworks have to deal with all possible keys, we end up with a much, much
more expensive data structure that has to be used just because numeric keys are being treated
specially.

This means that the real-world, application-level impact of not preserving order is *slower*
applications.

On 3/10/2011 5:48 PM, Boris Zbarsky wrote:

> On 3/10/11 8:44 PM, Charles Kendrick wrote:
>> It requires
>> browser vendors to implement order preservation, such that we don't get
>> the minor
>> optimization that's possible from not preserving order at all.
>
> For what it's worth, not preserving order for numeric properties allows optimizations that are
> decidedly not "minor".
>
> You can compare the performance of "fast" and "slow" arrays in Spidermonkey to see the difference.
>
> -Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Boris Zbarsky
On 3/10/11 9:00 PM, Charles Kendrick wrote:

> People use Objects as classes, instances, "associative arrays" / Maps,
> etc. Numeric keys are a tiny minority and there would be no measurable
> performance gains for special treatment of such keys *on Object*.

You may want to read
<https://bugzilla.mozilla.org/show_bug.cgi?id=594655> and
<https://bugzilla.mozilla.org/show_bug.cgi?id=611423>.  People are
running into performance issues due to lack of such special treatment today.

Now maybe these people are just doing dumb things they shouldn't be
doing, but that doesn't make the performance differences observed on
those tests "not measurable".

> However because frameworks have to deal with all possible keys, we end
> up with a much, much more expensive data structure that has to be used
> just because numeric keys are being treated specially.

I agree this is an issue.  I just think you're underestimating the
performance drag of preserving numeric property order for vanilla Objects.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
Boris, this is why I also took care to mention that for..in iteration on Arrays should remain
unordered, so that developers doing relatively obscure things like crypto evoting in JavaScript
(the use case in the first bug) still have access to a dense-array implementation.

Best of both worlds: Object does what you would expect, Array has optimizations for obscure use
cases.

Last point below.

----------
== Objections and counter-arguments

1. Array for..in iteration order has always been inconsistent across browsers

Yes, this is true.  I am proposing only that Object preserves insertion order, not Array.

No developers or sites rely on Array for..in iteration order, since it was never consistent.

If Array for..in iteration continues to be unordered, any developer that cares about the tiny
performance difference can use an Array to store non-numeric property/value pairs.
-----------

On 3/10/2011 6:11 PM, Boris Zbarsky wrote:

> On 3/10/11 9:00 PM, Charles Kendrick wrote:
>
>> People use Objects as classes, instances, "associative arrays" / Maps,
>> etc. Numeric keys are a tiny minority and there would be no measurable
>> performance gains for special treatment of such keys *on Object*.
>
> You may want to read <https://bugzilla.mozilla.org/show_bug.cgi?id=594655> and
> <https://bugzilla.mozilla.org/show_bug.cgi?id=611423>. People are running into performance
> issues due to lack of such special treatment today.
>
> Now maybe these people are just doing dumb things they shouldn't be doing, but that doesn't
> make the performance differences observed on those tests "not measurable".
>
>> However because frameworks have to deal with all possible keys, we end
>> up with a much, much more expensive data structure that has to be used
>> just because numeric keys are being treated specially.
>
> I agree this is an issue. I just think you're underestimating the performance drag of
> preserving numeric property order for vanilla Objects.
>
> -Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Boris Zbarsky
On 3/10/11 9:18 PM, Charles Kendrick wrote:
> Boris, this is why I also took care to mention that for..in iteration on
> Arrays should remain unordered

What does this have to do with the post you're replying to?

> so that developers doing relatively obscure things like crypto evoting in JavaScript (the use case in the
> first bug) still have access to a dense-array implementation.

The point is that the bignum library there is using vanilla objects, not
arrays.  And they're using numeric property names.

> If Array for..in iteration continues to be unordered, any developer that
> cares about the tiny
> performance difference can use an Array to store non-numeric
> property/value pairs.

1) They're not doing that now, necessarily, and there's no indication
that they'll start.

2) A factor of 6 is not a "tiny performance difference".

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Jeff Walden-6
In reply to this post by Boris Zbarsky
On 03/10/2011 06:11 PM, Boris Zbarsky wrote:
> You may want to read <https://bugzilla.mozilla.org/show_bug.cgi?id=594655> and <https://bugzilla.mozilla.org/show_bug.cgi?id=611423>. People are running into performance issues due to lack of such special treatment today.

Further to these points, it is possible that Firefox might change its property storage system to address bugs like these such that property enumeration order changes.  This would be <https://bugzilla.mozilla.org/show_bug.cgi?id=586842>.  I am not saying anything about how likely or unlikely this is.  I haven't really started to research the problem or brainstorm about potential solution space yet.  But we do see problems with arrays with non-index, non-length properties, and it's certainly possible that a fix which permits extra, non-indexed properties to be added to arrays without notably de-optimizing property storage, and subsequent property access, may affect property enumeration order.

Jeff
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

John Tamplin
In reply to this post by Charles Kendrick-2
On Thu, Mar 10, 2011 at 9:00 PM, Charles Kendrick <[hidden email]> wrote:
People use Objects as classes, instances, "associative arrays" / Maps, etc.  Numeric keys are a tiny minority and there would be no measurable performance gains for special treatment of such keys *on Object*.

An associative array is typically a hash map or perhaps a tree map.  A typical implementation will either iterate through such values in either an undetermined order or in order by the keys -- preserving the insertion order would be more expensive and preclude most options for implementation.

If you care about order, you don't use a hash map, and a JS object literal seems more closely related to a hash map than anything else.

An alternative you didn't consider in your original post is using a single array, which is guaranteed to not change the order and never pick up additional properties:

selectControl.setOptions([
     "storedValue1", "displayValue1",
     "storedValue2", "displayValue2",
     "storedValue3", "displayValue3"
])

--
John A. Tamplin
Software Engineer (GWT), Google

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
In reply to this post by Brendan Eich-3
Thanks for the link Brendan.

This strawman continues to treat numeric indices specially on Object.

Let's ignore, for the moment, the fact that the underlying implementation of Object and Array
is very similar.

Has a use case been identified where treating numeric properties differently from other
properties is a desirable behavior?

Is there any programming language or library for any programming language where this behavior
has been intentionally implemented as a collection class?

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.

On 3/10/2011 5:02 PM, Brendan Eich wrote:
> Please see http://wiki.ecmascript.org/doku.php?id=strawman:enumeration.
>
> /be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
In reply to this post by Boris Zbarsky
Boris, compare:

1. tens of thousands of web applications that need to define a sorted map plus perhaps billions
of JSON messages per day

.. to ..

2. a handful of crypto / computational use cases used by a tiny minority of sites

What should be optimized for?

Note that we don't really even have to choose.  If you tell the guys implementing these crypto
/ bignum libraries that their code is going to run 6x faster in Firefox if they use an Array,
they'll probably have switched by Tuesday.

It's a perfectly reasonable and acceptable way to close a bug to say that if you want the best
performance when using lots of numeric indices, use an Array.

On 3/10/2011 6:35 PM, Boris Zbarsky wrote:

> On 3/10/11 9:18 PM, Charles Kendrick wrote:
>> Boris, this is why I also took care to mention that for..in iteration on
>> Arrays should remain unordered
>
> What does this have to do with the post you're replying to?
>
>> so that developers doing relatively obscure things like crypto evoting in JavaScript (the use
>> case in the
>> first bug) still have access to a dense-array implementation.
>
> The point is that the bignum library there is using vanilla objects, not arrays. And they're
> using numeric property names.
>
>> If Array for..in iteration continues to be unordered, any developer that
>> cares about the tiny
>> performance difference can use an Array to store non-numeric
>> property/value pairs.
>
> 1) They're not doing that now, necessarily, and there's no indication that they'll start.
>
> 2) A factor of 6 is not a "tiny performance difference".
>
> -Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
In reply to this post by John Tamplin
On 3/10/2011 6:50 PM, John Tamplin wrote:
> If you care about order, you don't use a hash map, and a JS object literal seems more closely
> related to a hash map than anything else.

Object behaved like a LinkedHashMap for 15 years, and still does behave like a LinkedHashMap,
even in Chrome, except for numeric keys.

It seems like a very broadly held perception that Objects behave this way (based on the
record-setting 127 stars on Chrome's issue for this, if nothing else).

> An alternative you didn't consider in your original post is using a single array, which is
> guaranteed to not change the order and never pick up additional properties:
>
> selectControl.setOptions([
> "storedValue1", "displayValue1",
> "storedValue2", "displayValue2",
> "storedValue3", "displayValue3"
> ])

I'm aware, but omitted it because I thought it was an even worse option.

It has all the allocation / GC drawbacks of the other approaches mentioned: two Strings per
property vs just slots.  It also retains the drawback that developers have to build a secondary
index to avoid O(n) property change costs, and that this will be slower in practice, for real
applications.

On top of this, and perhaps worst of all, it has the further disadvantage that it looks like a
list of values.  You can't look at the code and see that values are being mapped to one another.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Brendan Eich-3
In reply to this post by Charles Kendrick-2
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Brendan Eich-3
On Mar 10, 2011, at 7:18 PM, Brendan Eich wrote:

> Harmony is *not* a clean break. I don't know why you wrote that.

Perhaps Charles meant "a clean break in for-in semantics".

That's what I propose via my index-finger compatibility break:


> 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 idea (http://brendaneich.com/2010/11/paren-free/, followups in http://brendaneich.com/2011/01/harmony-of-my-dreams/) is to relax the grammar so that parentheses may be omitted from statement heads where the parenthesized form is an expression, but to remove parens around the for loop heads (a la Go, for the three-part for ;; head). This requires that the body or then-clause be braced unless it is a simple statement that starts with an unconditionally reserved identifier.

The benefit for code migration is that for (x in o) ...; code will not compile in such a Harmony. Migrators will have to rewrite and (if necessary) choose a custom iterator to get the desired order and values or keys: for x in keys(o) {...;}, e.g. where keys is imported from a standard enumerators module.

This is less likely to break code than a subtle, runtime-only, and therefore "unclean" break in the meaning of for (x in o).

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Boris Zbarsky
In reply to this post by Charles Kendrick-2
On 3/10/11 9:58 PM, Charles Kendrick wrote:
> 1. tens of thousands of web applications that need to define a sorted
> map plus perhaps billions of JSON messages per day
>
> .. to ..
>
> 2. a handful of crypto / computational use cases used by a tiny minority
> of sites
>
> What should be optimized for?

It depends on the relative slowdowns, possibly.

And to be clear, all I was pointing out is that the speedup from
treating numbered properties specially is very noticeable and appears on
real-life workloads.  Where we go from there is a separate issue.

> Note that we don't really even have to choose. If you tell the guys
> implementing these crypto / bignum libraries that their code is going to
> run 6x faster in Firefox if they use an Array, they'll probably have
> switched by Tuesday.

I told them in September.  There's been no change yet.  I think you
overestimate how much people are willing to change their code to work
around what they think are bugs....

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: iteration order for Object

Charles Kendrick-2
In reply to this post by Brendan Eich-3
On 3/10/2011 7:18 PM, Brendan Eich wrote:
> On Mar 10, 2011, at 6:50 PM, Charles Kendrick wrote:
>> Has a use case been identified where treating numeric properties differently from other properties is a desirable behavior?
>
> If I'm reading you right, you don't mind us specifying arrays enumerating indexed "own" properties first and in index order.

Yes, exactly.  I understand the performance advantage here and I think Arrays should either do
exactly what's in the strawman or even not have a standardized iteration order (for maximum
optimization leeway).

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

You're correct, JQuery returns most query results as an Object where each matching element is
placed at a numeric index and it also does a lot of subsetting and traversal on such objects.

However, I doubt very much that the effect on JQuery of dense arrays could be shown outside of
synthetic benchmarks and very very niche use cases.  References would be great if you can find
them.

However large the effect on JQuery, I expect that a benchmark of a JavaScript LinkedHashMap
implementation as compared to native speed would be, I would guess, something like a 25x advantage.

Further, note that JQuery's use of Object is an implementation detail that may change in the
future.  Big chunks of JQuery are now shims for old browsers to duplicate HTML5/CSS3 native
support, and libraries are emerging that are roughly JQuery-compatible but directly return an
augmented native NodeList instead of an Object with indices:

        http://chocolatechipmobile.wordpress.com/

JQuery may well adopt this just as it adopted Sizzle, so it would be a shame to optimize the
language for such a short-lived advantage.

> Harmony is *not* a clean break. I don't know why you wrote that.

Quite right Brendan, sorry about that, I understand that it's designed as a more minimal break.
  Thanks for giving me the fingers ;)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345