On Nov 12, 2011, at 12:02 PM, Brendan Eich wrote:
On Nov 12, 2011, at 2:07 AM, Axel Rauschmayer wrote:
Embedded spreads is already in the ES6 draft for both array literals and
argument lists. I'm not at all sure that embedded rests in destructurings
are such a good idea.
I think it
On Nov 14, 2011, at 9:49 AM, Allen Wirfs-Brock wrote:
It's doable, but an additional implementation complication with a runtime cost
I felt this pain too, and even for the [a, ...r, b] case it's more pain. But
especially for function parameters.
We could leave it out. Symmetry fans (I'm one
On Nov 12, 2011, at 4:25 PM, Axel Rauschmayer wrote:
There is no requirement that ...r consume 1 element,
It consumes 0 elements above.
Sorry, misread your example -- we seem to agree that if there aren't enough
elements, r gets a fresh empty array.
/be
Embedded spreads is already in the ES6 draft for both array literals
and argument lists. I'm not at all sure that embedded rests in
destructurings are such a good idea. Just to start with, what does this
mean:
[a,b,...r,c,d = [1,2,3]
..
This sort of destructuring is not real pattern
Embedded spreads is already in the ES6 draft for both array literals and
argument lists. I'm not at all sure that embedded rests in destructurings
are such a good idea.
I think it would be nice to express “last element(s), e.g. in function
parameters (where the callback is usually at the
On Nov 12, 2011, at 12:48 AM, Claus Reinke wrote:
Embedded spreads is already in the ES6 draft for both array literals
and argument lists. I'm not at all sure that embedded rests in
destructurings are such a good idea. Just to start with, what does this
mean:
[a,b,...r,c,d = [1,2,3]
On Nov 12, 2011, at 2:07 AM, Axel Rauschmayer wrote:
Embedded spreads is already in the ES6 draft for both array literals and
argument lists. I'm not at all sure that embedded rests in destructurings
are such a good idea.
I think it would be nice to express “last element(s), e.g. in
This sort of destructuring is not real pattern matching. ..
I think this is the important point. Many of us who like destructuring
are still being mislead by the name, and by our experience with proper
pattern matching constructs.
You just used a different term, pattern matching, than
Just to start with, what does this mean:
[a,b,...r,c,d = [1,2,3]
That seems related to
[a, b, c, d] = [1,2,3]
and to
[a,b,...r,c,d] = [1,2,3,4]
Hence, I would guess:
a === 1
b === 2
r === []
c === 3
d === undefined
Why guess?
I’m not sure I understand.
There is no
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich 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,
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich 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
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich 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
A pattern of the form
[a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0]
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
Using this pattern for accessing elements at the end would be useful. For
example:
On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
A pattern of the form
[a0, a1, 〰〰, ak, ...r]
desugars to
a0 = %v[0];
a1 = %v[1];
〰〰
ak = %v[k];
let %length = %v.length;
do we sample the length here or at the
On Nov 11, 2011, at 4:23 PM, Axel Rauschmayer wrote:
It would be nice if r was optional:
[..., b0, b1, b2] = arr
Agreed. Pure win, no downside.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0]
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
I think it's a pretty big win, and I'd argue it's totally intuitive. The
great thing about destructuring is
On Nov 11, 2011, at 5:31 PM, Axel Rauschmayer wrote:
Also: we'll definitely want to allow it for splicing, so the grammar will
have to allow it already, and symmetry/consistency argue for allowing it in
destructuring too. Likewise for function formals and actuals.
Using it for splicing
On Nov 11, 2011, at 5:06 PM, David Herman dher...@mozilla.com wrote:
Also: we'll definitely want to allow it for splicing,
s/splicing/spread/
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Nov 11, 2011, at 5:06 PM, David Herman wrote:
On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
...
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
I think it's a pretty big win, and I'd argue
On 7 November 2011 18:42, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
or
let [first,second] = abc;
Yes, that's a more convincing example -- although we should probably
be aware that users will then also do
let [x, y, ...s] = somestring
and expect it to slice a string efficiently.
On 7 November 2011 22:46, Brendan Eich bren...@mozilla.com wrote:
On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
One possible semantics could be treating
let [x, y, z, ...r] = e
as equivalent to
let {0: x, 1: y, 2: z, ..._r} = e
let r = [].slice.call(_r, 3)
where I assume the
On Nov 8, 2011, at 4:01 AM, Andreas Rossberg wrote:
I was assuming that we want
let [x, y,z, ...r] = [1, 2, 3, 4, 5]
to bind r to [4, 5]. For that to hold, you have to shift down the
numeric indices in _r by 3, which is what the slice call was intended
to do.
Gotcha, my mistake --
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
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
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
On Sun, Nov 6, 2011 at 03:02, Brendan Eich bren...@mozilla.com wrote:
On Nov 5, 2011, at 5:52 PM, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 2:34 PM, Brendan Eich wrote:
On Nov 5, 2011, at 11:27 AM, Allen Wirfs-Brock wrote:
It should, as no length is assumed to mean length === 0, IIUC, and
One more thought: Should the following assignments produce the same result?
[x, y, z] = {length:0, 0:0, 1:1, 2:2}
[x, y, z] = [].slice.call({length:2, 0:0, 1:1, 2:2})
Then the decision boils down to whether an array conversion happens (however
implicitly) on the rhs or whether the lhs
On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Nov 5, 2011, at 11:01 AM, John J Barton wrote:
I can see why my version is wrong: I am interpreting square brackets
on the RHS like JS devs would.
let z = _rhs[0]; // LHS was array, so get zeroth elt,but RHS
On Nov 6, 2011, at 8:03 AM, John J Barton wrote:
On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
What do you think this returns:
Array.prototype.pop.call({0:0, 1:1, length: 2, 2:2})
The answer depends upon the definition of pop(). For an array
On Nov 6, 2011, at 6:32 AM, Axel Rauschmayer wrote:
One more thought: Should the following assignments produce the same result?
[x, y, z] = {length:0, 0:0, 1:1, 2:2}
[x, y, z] = [].slice.call({length:2, 0:0, 1:1, 2:2})
did you intend to use the same length value in both of the
On Sun, Nov 6, 2011 at 9:09 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 6, 2011, at 8:03 AM, John J Barton wrote:
On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
What do you think this returns:
Array.prototype.pop.call({0:0, 1:1, length:
One more thought: Should the following assignments produce the same result?
[x, y, z] = {length:2, 0:0, 1:1, 2:2}
[x, y, z] = [].slice.call({length:2, 0:0, 1:1, 2:2})
did you intend to use the same length value in both of the above lives?
Yes, corrected above.
Then the decision
On Nov 6, 2011, at 10:01 AM, Axel Rauschmayer wrote:
...
Very interesting. Still seems orthogonal to the decision whether or not to
coerce the rhs to array (whatever that means). If []= is considered an “array
operator” then coercion seems in line with how other operators behave.
If
If I wanted to ignore the length property, I would use:
let { 0: a, 1: b } = someValue
This is pretty much my thinking too. A programmer's choice to use [ ]
instead of {} the destructuring pattern means something. By choosing to use [
] as the pattern they are expressing the
On Nov 6, 2011, at 3:53 AM, Till Schneidereit wrote:
...
After thinking about this some more, I think I'd be fine with the
above outcome after all. It seems to me as though the array
destructuring pattern really only uses the syntax of arrays, not
necessarily their semantics. Once row
On Nov 6, 2011, at 11:18 AM, Allen Wirfs-Brock wrote:
On Nov 6, 2011, at 3:53 AM, Till Schneidereit wrote:
...
After thinking about this some more, I think I'd be fine with the
above outcome after all. It seems to me as though the array
destructuring pattern really only uses the syntax of
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be reasonable because it is an array pattern, and the source
object is only has two array-like elements
2 might be reasonable because the source
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)?
It seems to me that [2] is the right answer, and if that is the cause,
consistency requires that for the first problem z
On 05.11.2011 20:28, Allen Wirfs-Brock wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be reasonable because it is an array pattern, and the source object is
only has two array-like
On Nov 5, 2011, at 9:28 AM, Allen Wirfs-Brock wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be reasonable because it is an array pattern, and the source
object is only has
On 05.11.2011 20:38, 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)?
It seems to me that [2] is the right answer,
How so? If `...n` is the
On Nov 5, 2011, at 9:45 AM, Dmitry Soshnikov wrote:
On 05.11.2011 20:38, 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)?
It seems to me
On Nov 5, 2011, at 9:44 AM, Brendan Eich wrote:
On Nov 5, 2011, at 9:28 AM, Allen Wirfs-Brock wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be reasonable because it is an
To me the lhs indicates: array. Thus, the rhs is a pseudo-array. When used as
such we get:
[].join.call({0:0, 1:1, length: 2, 2:2}, -)
'0-1'
Thus, 2 is invisible. That’s what I would expect, too, intuitively. I’d think
that the assignment should reflect that (thus: z = undefined)
On
On Sat, Nov 5, 2011 at 9:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be reasonable because it is an array pattern, and the source
On Sat, Nov 5, 2011 at 5:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
(I assume the pattern should be [x,y,z], not [z,y,z], or am I missing a point?)
should it be be 2 or undefined
On 05.11.2011 20:49, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 9:38 AM, Dmitry Soshnikov wrote:
On 05.11.2011 20:28, Allen Wirfs-Brock wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined
On 05.11.2011 21:04, Dmitry Soshnikov wrote:
On 05.11.2011 20:54, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 9:45 AM, Dmitry Soshnikov wrote:
On 05.11.2011 20:38, 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};
On Nov 5, 2011, at 9:59 AM, Lasse Reichstein wrote:
On Sat, Nov 5, 2011 at 5:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
(I assume the pattern should be [x,y,z], not
On Nov 5, 2011, at 10:04 AM, Dmitry Soshnikov wrote:
On 05.11.2011 20:54, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 9:45 AM, Dmitry Soshnikov wrote:
On 05.11.2011 20:38, 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,
On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
(Oh great more features that turn programming into little brain teasers :-( )
Devs need an algorithm:
let _lhs = [];
let _rhs = {0:0, 1:1, length: 2, 2:2};
_lhs[0] = _rhs[0];
_lhs[1] = _rhs[1];
_lhs[2] = _rhs[2];
let z = _lhs[0];
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
and there I was, thinking I understood more than half of JS..
Since this was new to me, I referred to the spec. Here
strikeis my reading/strike are my readings:
The rhs is an Object, but
On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What if the RHS doesn't have a length property at all? Or it has one
with a value that isn't convertible to a number? No need for that
complexity.
This case is consistently handled throughtout the ES spec:
On Nov 5, 2011, at 10:57 AM, Claus Reinke wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
and there I was, thinking I understood more than half of JS..
Since this was new to me, I referred to the spec. Here strikeis my
On Nov 5, 2011, at 11:11 AM, Till Schneidereit wrote:
On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What if the RHS doesn't have a length property at all? Or it has one
with a value that isn't convertible to a number? No need for that
complexity.
This case
On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
On Sat, Nov 5, 2011 at 9:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
should it be be 2 or undefined
undefined might be
On Sat, Nov 5, 2011 at 19:27, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
ToInteger( obj.[[Get]](length))
evaluates to 0 if length is missing or has a bogus value.
So in your favored solution, would the following example result in x,
y, and z all being undefined?
let [x,y,z] = {0:0,
On Sat, Nov 5, 2011 at 11:55, Brendan Eich bren...@mozilla.com wrote:
The issue with ... in an array destructuring pattern is different from the
case without. We have a choice, as you say. It's not obvious that doing a
get of 'length' on the RHS (once per ...) is the right answer. It's
On Nov 5, 2011, at 10:24 AM, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
(Oh great more features that turn programming into little brain teasers :-( )
Devs need an algorithm:
let _lhs = [];
let _rhs = {0:0, 1:1, length: 2, 2:2};
_lhs[0] = _rhs[0];
On Nov 5, 2011, at 11:01 AM, John J Barton wrote:
I can see why my version is wrong
Your interpretion is not wrong.
But the feature does not do this. Rather, since LHS is array, it
coerces the RHS to an array:
let z = coerceToArray(_rhs)[0];
and we don't know what that operation means.
On Sat, Nov 5, 2011 at 14:41, Brendan Eich bren...@mozilla.com wrote:
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
prefs in
On Nov 5, 2011, at 12:38 PM, Erik Arvidsson wrote:
On Sat, Nov 5, 2011 at 11:55, Brendan Eich bren...@mozilla.com wrote:
The issue with ... in an array destructuring pattern is different from the
case without. We have a choice, as you say. It's not obvious that doing a
get of 'length' on
On Nov 5, 2011, at 2:28 PM, Brendan Eich wrote:
On Nov 5, 2011, at 10:24 AM, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
...
I don't understand what the source object is only has two
array-like elements can mean.
If you used any of the array
On Nov 5, 2011, at 2:34 PM, Brendan Eich wrote:
On Nov 5, 2011, at 11:27 AM, Allen Wirfs-Brock wrote:
It should, as no length is assumed to mean length === 0, IIUC, and
that seems so unintuitive to me that it sways my opinion towards not
imposing array-ness on the RHS.
but that is
On Nov 5, 2011, at 3:50 PM, Erik Arvidsson wrote:
On Sat, Nov 5, 2011 at 14:41, Brendan Eich bren...@mozilla.com wrote:
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
On Nov 5, 2011, at 5:40 PM, Allen Wirfs-Brock wrote:
In general, destructuring already has too many moving parts to simply be a
simple desugaring. array/object distinctions, rests on the LHS, default
value specifiers, etc. I'm specifying it like any other feature in the
language.
Take
On Nov 5, 2011, at 5:52 PM, Allen Wirfs-Brock wrote:
On Nov 5, 2011, at 2:34 PM, Brendan Eich wrote:
On Nov 5, 2011, at 11:27 AM, Allen Wirfs-Brock wrote:
It should, as no length is assumed to mean length === 0, IIUC, and
that seems so unintuitive to me that it sways my opinion towards
78 matches
Mail list logo
