Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Erik Arvidsson
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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] =

Re: An array destructing specification choice

2011-11-05 Thread Erik Arvidsson
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Till Schneidereit
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Till Schneidereit
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.[[

Re: An array destructing specification choice

2011-11-05 Thread John J Barton
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}; >>

Re: An array destructing specification choice

2011-11-05 Thread Claus Reinke
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 -

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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:

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Dmitry Soshnikov
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

Re: An array destructing specification choice

2011-11-05 Thread Dmitry Soshnikov
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

Re: An array destructing specification choice

2011-11-05 Thread Dmitry Soshnikov
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

Re: An array destructing specification choice

2011-11-05 Thread Lasse Reichstein
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

Re: An array destructing specification choice

2011-11-05 Thread John J Barton
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

Re: An array destructing specification choice

2011-11-05 Thread Axel Rauschmayer
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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)? >> >>

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Re: An array destructing specification choice

2011-11-05 Thread Dmitry Soshnikov
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

Re: An array destructing specification choice

2011-11-05 Thread Brendan Eich
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

Re: An array destructing specification choice

2011-11-05 Thread Dmitry Soshnikov
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"

Re: An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

An array destructing specification choice

2011-11-05 Thread Allen Wirfs-Brock
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

Unicode fantasy arrows

2011-11-05 Thread Allen Wirfs-Brock
If only we could use any Unicode character, then <| might look like: ◀ but this is more symbolic of what is actually going on: ⥆ of course if we are talking about classes with parallel inheritance hierarchies it might be better to use: ⇇ And who could resisting trying to make one