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
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Mike Shaver
Sent: Tuesday, October 13, 2009 4:05 PM
To: David-Sarah Hopwood
Cc: es-discuss@mozilla.org
Subject: Re: Strategies for standardizing mistakes
On Tue, Oct 13, 2009 at
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 10/13/2009 04:05 PM, Mike Shaver wrote:
On Tue, Oct 13, 2009 at 7:01 PM, David-Sarah Hopwood
david-sa...@jacaranda.org wrote:
I agree with Maciej. The implementation-defined operations have clear
specifications of their parameters. I think that it is highly undesirable
to adopt an
One could characterize the difference by saying that Mozilla has
reluctant properties whereas WebKit has reluctant values. :)
In other words, in WebKit, 'document.all' has a value --- a value that
can be assigned to other variables, stored in data structures, and so on
without changing its
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
On Wed, Oct 14, 2009 at 7:40 PM, Jim Blandy j...@mozilla.com wrote:
There's one specific kind of contextual information that's being looked at
askance here: knowledge of the expression surrounding the call that invoked
you. Perl lets subroutines check what sort of value their caller is
It's probably too late for us to take advantage of this, but it did just occur
to me (too much document.all discussion) that since for-in is a syntactic
construct its behavior could be different in strict mode, potentially allowing
us to define a for-in enumeration order that isn't tried to
Sure, but again... Without any changes it currently reads:
The mechanics and order of enumerating the properties (step 6.a in
the first algorithm, step 7.a in the second) is not specified.
Which isn't really necessary even currently (pre-5 I think) doesn't
accurately describe what seems to be
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
22 matches
Mail list logo
