On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Nope, it's always been designed this, going back to the original wiki
strawman
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I
assume the original FF implementation.
It has also
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g()// 1, 2
{a: f().x} = {a: g(}} // 2, 1
That is, destructuring assignments
On Apr 25, 2014, at 4:24 AM, Andreas Rossberg rossb...@google.com wrote:
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g
On Apr 25, 2014, at 10:25 AM, Oliver Hunt wrote:
On Apr 25, 2014, at 4:24 AM, Andreas Rossberg rossb...@google.com wrote:
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o
evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g()// 1, 2
{a: f().x} = {a: g(}} // 2, 1
That is, destructuring assignments violate the left-to-right
evaluation that is otherwise maintained.
I don’t
On Apr 25, 2014, at 11:45 AM, Oliver Hunt wrote:
o = {__proto__: {set foo() {print(“bar”)}}
o.foo = (o.__defineSetter__(“foo”, function(){ print(“foo”)})), 5
1) o.f evaluates to a Reference whose base is the value of 0 and whose
referenced name is foo. No lookup occurs at this point.
2)
Yes, this is intentional and goes all the way back to ES4's original
destructuring proposal, based on array-pattern destructuring implemented
in Opera's Futhark engine. See
http://wiki.ecmascript.org/doku.php?id=discussion:destructuring_assignment#contrast_to_normal_assignment
We want
On Oct 18, 2013, at 12:24 PM, BelleveInvis wrote:
...this causes an inconsistency that in expression `[f().x] = [g()]`, g is
called BEFORE f. That is weird, and differ from `f().x = g()` where g is
called after f.
but consider
[f().x, h().y] = g(); //assume g() evaluates to an
Hi,
Some quick testing with Firefox seems to show that for-in returns
properties in the order they were added to the object, and some scripts
on the web (eg. RaphaelJS) seem to depend on that, unless I'm
horrendously misinterpreting them. This seems... bad?
Are objects implicitly ordered,
On 12/27/10 5:39 AM, Michael Day wrote:
Some quick testing with Firefox seems to show that for-in returns
properties in the order they were added to the object
Yep; it's required for web compat, as you discovered. When we
accidentally broke it, we very quickly got bug reports. ;)
and
On 27.12.2010 14:39, Michael Day wrote:
Hi,
Some quick testing with Firefox seems to show that for-in returns
properties in the order they were added to the object, and some
scripts on the web (eg. RaphaelJS) seem to depend on that, unless I'm
horrendously misinterpreting them. This seems...
Thanks Boris, Dmitry,
Are objects implicitly ordered, by implementation convention?
For implementations that have to deal with the web, yes.
Okay, now I know what we have to do then :)
Might I suggest that this be added to the spec, if only in an
informative note, to save future
Note that almost all implementations break for-in enumeration order for dense
arrays, for some definition of dense.
Example (firefox):
a = []
a[2] = 1
a[1] = 1
a[0] = 1
for (i in a) alert(i)
will alert 0, 1, 2 (in that order).
Now if you do
a[x] = 1
you get 0, 1, 2, x
However, if we start
Hi Andreas,
Note that almost all implementations break for-in enumeration order for dense
arrays, for some definition of dense.
This is understandable and very sensible.
If we try to specify something, implementors will probably object, and each
implementation will have specific
On 27.12.2010 15:40, Andreas Gal wrote:
I can't speak for other VM implementors, but I think most implementors will not want to
guarantee either enumeration method (property addition order vs numeric order). In some
cases we store array data dense, in others we punt and use a natural object
On Mon, Dec 27, 2010 at 9:54 AM, Wes Garland w...@page.ca wrote:
I think Mark's suggestion here is very sensible. My gut tells me that it
has a low probability of breaking the web, yet it offers room for
implementers to provide a fast path for numeric object indices while
offering an
Dave, under the spec for Operation OwnProperties(obj) step 1, you don't
explicitly state that these index properties are to be enumerated in numeric
order. An oversight?
Oops, yes, thanks for catching that. I've updated the wiki.
Also, you misstate that indexes are properties with values
On 27.12.2010 20:54, Wes Garland wrote:
On Mon, Dec 27, 2010 at 8:04 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
Can you also show a memory representation (at lower level) of
dense and sparse (?) data. It will help to understand the
The es-discuss and es5-discuss lists have seen this topic before. I don't
always remember names of people who sent messages, but I keep complete
archives, search them locally, then search the web for a decent archive.
Possibly others do the same and can provide links.
Here's a good one to
On 2010-12-27 19:15, David Herman wrote:
Dave, under the spec for Operation OwnProperties(obj) step 1, you don't
explicitly state that these index properties are to be enumerated in numeric
order. An oversight?
Oops, yes, thanks for catching that. I've updated the wiki.
The given
left-to-right evaluation order (as the concept is likely to be
understood by typical users of the language) is wrong. For consistency,
Dave-Sarah's observation that we first evaluate and then coerce the
operands is probably the guideline we should continue to follow if we ever
define any
Message-
From: es5-discuss-boun...@mozilla.org
[mailto:es5-discuss-boun...@mozilla.org] On Behalf Of David-Sarah Hopwood
Sent: Friday, November 20, 2009 7:18 PM
To: es5-disc...@mozilla.org
Subject: Re: ES5 left-to-right evaluation order issues
Allen Wirfs-Brock wrote:
So, the main point
22 matches
Mail list logo
