Bradley, the proposal is to define the iteration order for Object only, not all
objects (eg Array).
Also, if you were choosing between:
1. The strawman: preserve insertion order for non-index properties only, on
both Object and Array
2. My proposal: preserve insertion order for all properties on Object only,
leave other objects undefined
Then what would you choose? Because there seems to be existing momentum to
define an order of iteration, so it may be that what you seem to prefer (leave
it totally undefined) is not a possibility.
On Mar 11, 2011, at 5:55 PM, Bradley Meck <bradley.m...@gmail.com> wrote:
> I would just like to give my 2 cents.
>
> I would like some sort of iterative ordering, but not on Objects. The
> reasons have been stated before that iterative ordering is less
> optimal for performance than random access (or semi-random). However,
> it has its uses, perhaps it would be more suitable to put this in
> proxies like people have stated, which in some ways is true.
> Lexiconographical and declaration orderings are quite different but
> quite common, and even then there could be a more obscure ordering
> that is left out. This topic I feel is a complex one that has
> implementation implications if we provide it on all objects, as well
> as the added complexity of runtime mutation of properties needing
> consideration (it would be odd for object literals to be treated
> differently from other objects). As well as the possible reliance of
> people on object indexes which have no real ordering:
>
> var i = 0
> for(var k in obj) {
> switch(i) {
> //stuff based upon i instead of k to determine your actions even
> though relying on k as a context when producing the object
> }
> i++
> }
>
> is a confusing but possible code example of independence of properties
> and location that would be awkward. If we do go with ordering, this is
> a possible example of misuse (it is a simple case but would be
> throwing around junk strings of k without really wanting to know what
> k actually says).
>
> For now I would stick with arrays for ordering as ordering multiple
> objects together implies a relationship which should be encapsulated
> (because they are related somehow rather than by implicit knowledge of
> how ordering is going to line them up) in another object rather than
> symbol table. And I hope we get proxy support everywhere so we can do
> interesting for ... in loops soon.
>
> I am going to side with voting no on this. It seems that the idea of
> sorted enumeration is a great one, but the reasons to put it on the
> enumeration of objects is less than stellar. Most of the reasons
> appear to be due to legacy systems or possible memory saving, but I am
> not convinced you would save memory/cpu due to the need of
> tracking/sorting this order of properties whenever a for in loop is
> performed (assuming we can do it lazily). In reality I see it as a
> native code implementation of what is being done with libraries today
> when they do need to keep track of multiple fields at the same time,
> but a reliance on this would mean instead of only doing it as needed,
> the native implementation would perform this every single time,
> slowing down setting of properties as well as all for ... in loops.
>
> Cheers,
> Bradley
>
> On Fri, Mar 11, 2011 at 6:31 PM, Charles Kendrick
> <char...@isomorphic.com> wrote:
>> On 3/11/2011 3:58 PM, Jeff Walden wrote:
>>>
>>> On 03/11/2011 02:07 PM, Charles Kendrick wrote:
>>>>
>>>> Your perspective is common in a group like this - very spec and standard
>>>> focused. Isn't it
>>>> fun to bash those developers? Everyone's doing it.. I hope you realize
>>>> it's irrelevant though?
>>>
>>> Insinuating bad faith ("Isn't it fun" and "Everyone's doing it") may not
>>> be a successful
>>> strategy for swaying others to your point of view. Just saying.
>>
>> My apologies. It is frustrating to open a discussion with a proposal of
>> what is best, and have it be redirected repeatedly into a discussion of who
>> is to blame.
>>
>>> And I tend to agree with David Bruant about the makeup of the list being
>>> lightly-involved
>>> developers, true standardistas, implementers, spec writers, and more: a
>>> fairly mixed bunch with
>>> lots of different motivations and goals, to which few generalized
>>> sentiments can fairly be
>>> attributed.
>>
>> You're certainly correct that it's a mixed bunch of roles, but that's within
>> the very narrow subset of developers who know about the standards process
>> and care enough to be here.
>>
>> However I would never attribute a general sentiment to any group, that's
>> almost always wrong. I said a certain perspective would be more common.
>> It's been my (repeated) personal experience that you get very different
>> responses on a list devoted to standards than from (say) an enterprise
>> development shop. Easily verified.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
