On Sat, Nov 5, 2011 at 10:41 PM, Brendan Eich bren...@mozilla.com wrote:
We have:
1. Should an array pattern always query 'length'?
2. If the answer to (1) is no, then should ... in an array pattern query
'length'?
On reflection and at this point in the thread, with your reply in mind, my
On 5 November 2011 17:44, Brendan Eich bren...@mozilla.com wrote:
Destructuring is irrefutable in that it desugars to assignments from
properties of the RHS. It is not typed; it is not refutable
I don't think that's true, at least not in the usual sense of
irrefutable pattern. Because you can
On 5 November 2011 19:55, Brendan Eich bren...@mozilla.com wrote:
On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
In a similar vain, what is the value of r in:
let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
should it be [2] or [2,3,4] (and if the latter how is that determined)?
I.e., I think the most easily comprehensible behavior is to make array
destructuring treat the RHS as an Array.
It matches the common use-case (actual arrays), it is consistent (does
the same whether you use ... or not), and is easily explainable.
I agree with the consistency argument. The
Hi,
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the
way in which these algorithms climb the prototype chain:
http://wiki.ecmascript.org/doku.php?id=strawman:refactoring_put
This is mainly
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
On 5 November 2011 17:44, Brendan Eich bren...@mozilla.com wrote:
Destructuring is irrefutable in that it desugars to assignments from
properties of the RHS. It is not typed; it is not refutable
I don't think that's true, at least not in
On 7 November 2011 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
let {x} = 666
which will be refuted, by raising a TypeError.
No,
It does ToObject(666) and then looks for the x property of the resulting
wrapper object.
Ouch, really? I don't see that in the proposal
On 7 November 2011 17:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It is just another way to
silently inject an `undefined' that is tedious to track down. We
already have too many of those...
It is how the language currently behaves in all situations where an object is
needed but a
How about:
let {length} = abc;
I think the conversion keeps the illusion alive that every value in JS is an
object.
On Nov 7, 2011, at 18:21 , Andreas Rossberg wrote:
On 7 November 2011 17:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It is just another way to
silently inject an
On Nov 7, 2011, at 9:32 AM, Axel Rauschmayer wrote:
How about:
let {length} = abc;
or
let [first,second] = abc;
I think the conversion keeps the illusion alive that every value in JS is an
object.
On Nov 7, 2011, at 18:21 , Andreas Rossberg wrote:
On 7 November 2011 17:34,
On Nov 7, 2011, at 9:21 AM, Andreas Rossberg wrote:
On 7 November 2011 17:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It is just another way to
silently inject an `undefined' that is tedious to track down. We
already have too many of those...
It is how the language currently
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
Claus Reinke could not submit his js-tools discussion group
announcement (interestingly, I could do it for him). And the email I
appended underneath my signature never got through. Can someone
explain the blocking criteria?
I have experienced
On 11/7/11 2:48 PM, David Bruant wrote:
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
Claus Reinke could not submit his js-tools discussion group
announcement (interestingly, I could do it for him). And the email I
appended underneath my signature never got through. Can someone
explain the
Claus Reinke could not submit his js-tools discussion group announcement
(interestingly, I could do it for him). And the email I appended underneath
my signature never got through. Can someone explain the blocking criteria?
I have experienced similar problems at some point. I don't know what
We use Google Postini in concert with Mailman. Postini needs to be told
sometimes. If you don't see mail get through, mail es-discuss-ow...@mozilla.org
about it.
/be
On Nov 7, 2011, at 12:48 PM, David Bruant wrote:
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
Claus Reinke could not
On Nov 7, 2011, at 12:59 AM, Lasse Reichstein wrote:
If the object being destructured is in fact a plain Array, with no
inherited elements above the length, then there is no difference.
This is most likely the (very) common use case. This is what the ES
programmers' intuition will be based
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
On 5 November 2011 17:44, Brendan Eich bren...@mozilla.com wrote:
Destructuring is irrefutable in that it desugars to assignments from
properties of the RHS. It is not typed; it is not refutable
I don't think that's true, at least not in
On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
On 5 November 2011 19:55, Brendan Eich bren...@mozilla.com wrote:
On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
In a similar vain, what is the value of r in:
let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
should it be
On Nov 7, 2011, at 10:03 AM, Allen Wirfs-Brock wrote:
True, in and instanceof don't follow the rules. I note that they were
added in ES3 and I have to wonder if they aren't another case of features
being added without sufficient thought being given to maintaining consistency
of behavior
Hi Tom,
Thanks for all this work!
Le 07/11/2011 16:54, Tom Van Cutsem a écrit :
Hi,
I wrote up an initial (but fairly complete) draft of a proposed
refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms
to change the way in which these algorithms climb the prototype
chain:
The November 7, 211 (also known as Rev 4) draft is available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Let me know if you really need to docx format copy and I'll send it two you. I
haven't found a way to get docuwiki to allow me to upload docx files. It seems
21 matches
Mail list logo
