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 b
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.
>>
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
_
>>> 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
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 "des
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
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
> 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 t
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 match
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
On Nov 11, 2011, at 5:06 PM, David Herman 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: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 s
>>> [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 destructu
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
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
>> 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
exam
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 patte
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 patter
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 th
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 7 November 2011 22:46, Brendan Eich 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 7 November 2011 18:42, Allen Wirfs-Brock 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.
/Andreas
__
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 beh
On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
> On 5 November 2011 19:55, Brendan Eich 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
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
> On 5 November 2011 17:44, Brendan Eich 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 s
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 9:21 AM, Andreas Rossberg wrote:
> On 7 November 2011 17:34, Allen Wirfs-Brock 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 a
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
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 wrote:
>>> It is just another way to
>>> silently inject an `undefined' that
On 7 November 2011 17:34, Allen Wirfs-Brock 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 primitive val
On Nov 7, 2011, at 3:50 AM, Till Schneidereit wrote:
>> 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 easi
On Nov 6, 2011, at 9:13 PM, Brendan Eich wrote:
> 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 tho
On Nov 7, 2011, at 8:23 AM, Andreas Rossberg wrote:
> On 7 November 2011 17:07, Allen Wirfs-Brock 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.
>
On 7 November 2011 17:07, Allen Wirfs-Brock 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
(http://wiki.ecmascri
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
> On 5 November 2011 17:44, Brendan Eich 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
> 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 5 November 2011 19:55, Brendan Eich 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)?
>
> The
On 5 November 2011 17:44, Brendan Eich 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 write
let {
On Sat, Nov 5, 2011 at 10: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, with your reply in mind, my
> prefs
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
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 ro
>> 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
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
>> 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
On Sun, Nov 6, 2011 at 9:09 AM, Allen Wirfs-Brock 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
>> wrote:
>>>
>>>
>>> What do you think this returns:
>>> Array.prototype.pop.call({0:0, 1:1, length: 2, 2:2})
>>
>> The answer
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 t
On Nov 6, 2011, at 8:03 AM, John J Barton wrote:
> On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
> 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 argument
> we c
On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
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 is
> object so p
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 Sun, Nov 6, 2011 at 03:02, Brendan Eich 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
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 opi
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.
Tak
On Nov 5, 2011, at 3:50 PM, Erik Arvidsson wrote:
> On Sat, Nov 5, 2011 at 14:41, Brendan Eich 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
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.
>>
>> b
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 us
On Nov 5, 2011, at 12:38 PM, Erik Arvidsson wrote:
> On Sat, Nov 5, 2011 at 11:55, Brendan Eich 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 (onc
On Sat, Nov 5, 2011 at 14:41, Brendan Eich 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 order: [no, y
On Nov 5, 2011, at 12:38 PM, Erik Arvidsson wrote:
> On Sat, Nov 5, 2011 at 11:55, Brendan Eich 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
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 exactly how it works everywhere else length is u
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 mean
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] =
On Sat, Nov 5, 2011 at 11:55, Brendan Eich 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
> plausible in my vi
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)?
The inspiration for ... in the past came from (among other
On Sat, Nov 5, 2011 at 19:27, Allen Wirfs-Brock 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, 1:1, 2:2
On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
> On Sat, 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 reasonabl
On Nov 5, 2011, at 11:11 AM, Till Schneidereit wrote:
> On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock 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 co
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 is
> object so property access.
>
> But the feature does not do this. Ra
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 is my
> rea
On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock 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:
> ToInteger( obj.[[
On Sat, 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};
>>
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
is my reading are my readings:
The rhs is an Object, but not an Array -
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
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:
On Nov 5, 2011, at 9:59 AM, Lasse Reichstein wrote:
> On Sat, Nov 5, 2011 at 5:28 PM, 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};
>
> (I assume the pattern should be [x,y,z], not [z,y,z], or am I mi
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};
sh
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};
should it be [2] or [2,3,4] (and if the latter
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 mig
On Sat, Nov 5, 2011 at 5:28 PM, 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};
(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
If it does anyth
On Sat, 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 onl
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 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 bec
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)?
>>
>>
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 might be reasonable because i
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 ran
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
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"
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 g
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 sourc
88 matches
Mail list logo
