On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich <bren...@mozilla.com> wrote:
> Andreas Rossberg wrote:
>>
>> I haven't replied to this thread yet, because I feel that I already
>> made all the same arguments repeatedly to no avail. ;) However, let
>> me reiterate one particular observation, which is that IMHO much of
>> the discussion (and decision making) around 1JS, modes, and opt-ins is
>> just mistargeted.
>
>
> Could be, let's see.
>
>
>> Namely, it is primarily based on the expectations and needs of
>> _current_ users. Users that are aware of what's ES3 or 5 and who are
>> about to investigate what's new in ES6. To those users, design choices
>> like making new constructs opt into strict mode by default will not
>> seem a big deal, even natural.
>
>
> Glad to hear some concurrence.
>
>
>> But that group will be irrelevant after a relatively short time of
>> transition!
>
>
> Who knows? "Relatively short time" will be measured in units of years,
> though.
>
>
>> ES6+ will stay much longer (at least that's what we are working for).
>> Consequently, what should take precedence are the expectations and
>> needs of _future_ users of ES. Those who will come to ES6+ without
>> knowing nor caring about the colorful history of its earlier versions.
>> For them, having various features locally change the semantics of
>> unrelated constructs
>
>
> Whoa.
>
> Who ever proposed that? It seems a misunderstanding. No one is saying that,
> e.g., destructuring formal parameters, or a rest parameter, should flip the
> containing function into strict mode. Banning duplicate formals in no wise
> does that.
This is an example of the micro-modes issue. If optional, rest, and/or
destructuring needs to enforce no duplicates, then we have two
choices:
1) Make these features available only in strict code, which doesn't
require any new special case -- since strict already bans duplicate
parameter names.
2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity of dealing with one mode switch.
By our previous criteria, #1 is obviously simpler than #2.
>
> So what exactly are you referring to here, in the way of a live proposal?
>
> /be
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
