sense and
other times it won't.
Allen
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Wednesday, October 14, 2009 10:26 PM
To: Allen Wirfs-Brock
Cc: Mike Shaver; Waldemar Horwat; es-discuss
Subject: Re: Property Iteration in JSON serialization
On Oct 14, 2009
Iteration in JSON serialization
On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
Similarly, rather than trying to fully specifying for-in enumeration
order (and invariably causing potentially breaking changes for some
implementations)
I'm focusing on your parenthetical aside: we have precedent
If I recall correct, Opera has a weird behaviour where it follows a
certain predictable ordering - unless you're deleting/removing a
property (or use prototype functions that do that in their operation)
on an object, which radically changes the sorting order in a way that
is only predictable with
On Tue, Oct 13, 2009 at 10:54 PM, Luke Smith lsm...@lucassmith.name wrote:
On Oct 13, 2009, at 9:24 PM, Brian Kardell wrote:
There are potentially some additional practical upshots beyond human
readability to this which I won't get into here until I find out: Is
it even plausible to
Currently FF3.5.4 doesn't properly apply replacer functions, but
Safari 4, WebKit, IE8, and Chrome 3 work fine for this task.
For the purpose of discussion webkit and safari (and epiphany, and
arora, ...) are synonymous -- chrome represents the only version of
webkit using a unique JS
On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote:
All ES implementations are required to enumerate object properties
in the order of insertion, regardless of internal representation,
and the JSON object definition defines the replacer execution in
terms of that standard object enumeration.
On Wed, Oct 14, 2009 at 5:41 AM, Patrick Mueller pmue...@yahoo.com wrote:
On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote:
All ES implementations are required to enumerate object properties in the
order of insertion, regardless of internal representation, and the JSON
object definition defines
Siterer Brendan Eich bren...@mozilla.com:
All ES implementations are required to enumerate object properties in the
order of insertion, regardless of internal representation
Is it required - or is it not?
It's not (yet) a spec requirement but in our experience it is
definitely required
Brian Kardell wrote:
Uh oh... Patrick looking at the same parts as me reacting the same way
(I believe older pre-5 docs also said something similar)...
When Oliver said All ES implementations are required to... I assumed
that I missed something in the new 5 docs - not that everyone just
seems to
The issue is not overriding default for-in behavior (as you can do in
JS1.7 via __iterator__). The issue is the default behavior.
Waldemar's right, browsers differ on Array enumeration, for some or
all Arrays. My observation to TC39 when we last discussed this is that
most arrays are
Brian Kardell wrote:
It sounds to me like there is wide agreement in the sense that at
least the basics rules and only disagreement on the fringes...
Otherwise no one on this list in particular would be suggesting that
there is anything remotely like a de facto implementation... It
seems that at
On 10/13/2009 10:54 PM, Luke Smith wrote:
Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
4, WebKit, IE8, and Chrome 3 work fine for this task.
How precisely are replacer functions not properly applied in Firefox? I
remember reporting at least one bug on the
On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat walde...@google.com wrote:
No. As I wrote, there is no de-facto implementation order because the
implementations do not agree on the order in general, and what you call
fringes such as numbers do matter. Trying to force, say, insertion order
On Wed, Oct 14, 2009 at 7:39 PM, Jeff Walden jwalden...@mit.edu wrote:
On 10/13/2009 10:54 PM, Luke Smith wrote:
Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
4, WebKit, IE8, and Chrome 3 work fine for this task.
How precisely are replacer functions not properly
To: Waldemar Horwat
Cc: es-discuss
Subject: Re: Property Iteration in JSON serialization
On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat walde...@google.com
wrote:
No. As I wrote, there is no de-facto implementation order because the
implementations do not agree on the order in general, and what you
-discuss
Subject: Re: Property Iteration in JSON serialization
On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat walde...@google.com
wrote:
No. As I wrote, there is no de-facto implementation order because the
implementations do not agree on the order in general, and what you
call
fringes
Sorry... somehow Waldemar's comment got closed up in my Gmail
conversation stack and I missed this comment...
If Oliver and Hallvord and Brendan are wrong on the idea that it is
at least largely already a de facto standard for non-indexed
properties then I suppose it is a moot point...
On
On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
Similarly, rather than trying to fully specifying for-in enumeration
order (and invariably causing potentially breaking changes for some
implementations)
I'm focusing on your parenthetical aside: we have precedent in Harmony
On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:
Sorry... somehow Waldemar's comment got closed up in my Gmail
conversation stack and I missed this comment...
If Oliver and Hallvord and Brendan are wrong on the idea that it is
at least largely already a de facto standard for non-indexed
On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:
Sorry... somehow Waldemar's comment got closed up in my Gmail
conversation stack and I missed this comment...
If Oliver and Hallvord and Brendan are wrong on the idea that it is
at least largely already a de facto standard for non-indexed
On Oct 14, 2009, at 10:47 PM, Maciej Stachowiak wrote:
(*) - If you use constructor functions to make an object with
properties named (x, y, z) added in that order, with a prototype
that has properties (a, b, c), and in turn has a prototype with
properties (q, r, s), JSC and
Brian Kardell wrote:
So - keeping in mind that the instance and the serialization are
separate things - what if I would like to order my serialization keys
(property names) in natural order? It has no impact on the parsing or
internal representation, but imposing a known order on the
David-Sarah Hopwood wrote:
[*] Do any common implementations actually do that, other than for
packed arrays?
Yes. All the fast ones. Nitro (nee sfx), v8 and spidermonkey all
synthesize structural type descriptors (shapes) at runtime and store
packed instances, tagged by shape. It's an
On Oct 13, 2009, at 9:24 PM, Brian Kardell wrote:
There are potentially some additional practical upshots beyond human
readability to this which I won't get into here until I find out: Is
it even plausible to accomplish this with new built in JSON supports?
To be specific, if it's not
24 matches
Mail list logo
