An array destructing specification choice

[Allen Wirfs-Brock]

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, Allen Wirfs-Brock <allen at 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 primitive values is provided.
>>>  We want consistency in language design, not a hodgepodge of special cases and different rules.
>> 
>> Hm, I don't quite buy that. There are plenty of places in ES today
>> where we don't convert but throw, e.g. "in", "instanceof", various
>> methods of Object, etc.  Destructuring arguably is closely related to
>> operators like "in".  Implicit conversion would violate the principle
>> of least surprise for either, IMHO.
>> 
>> I agree that consistency is a nice goal, but it seems like that train
>> is long gone for ES. Also, if consistency implies proliferating an
>> existing design mistake then I'm not sure it should have the highest
>> priority.
>> 
>> 
>>>> When would this ever be useful behaviour instead of just obfuscating bugs?
>>> 
>>> let {toFixed, toExponential} = 42;
>> 
>> OK, I guess "useful" is a flexible term. Would you recommend using
>> that style as a feature?
>> 
>> /Andreas
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> 
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111107/92dbbc1b/attachment-0001.html>