Stricter "use strict"
francisco.m.s.ferreira at gmail.com
Tue Apr 16 04:45:48 PDT 2013
Thanks Andreas that was a great input.
But in that case the original question still stands, are more modes planed?
Although the solution with the "restricter pluggin" would work, it would
also be cool to have a native "more strict" solution. Given your answer, "Not
them there would have simplified matters.", then it would force the
language to evolve. i.e.: "If you want to use feature X you must write your
code as required by mode Y". Note that as "use strict", any new mode would
have to be backwards compatible in terms of syntax, the only difference
would be that the call to "new feature X" would just output a warning to
the console, do nothing, and continue.
Alternative with multiple modes maybe we could provide the developers with
configurable options where they can explicitly activate/deactivate certain
On Tue, Apr 16, 2013 at 1:15 PM, Andreas Rossberg <rossberg at google.com>wrote:
> On 16 April 2013 12:15, David Bruant <bruant.d at gmail.com> wrote:
> > Le 16/04/2013 11:54, Andreas Rossberg a écrit :
> >> On 16 April 2013 11:12, David Bruant <bruant.d at gmail.com> wrote:
> >>> TC39 (which I'm not part of) agreed to not add more modes to
> >>> They try to follow the "1JS" rule, that is there is only one language.
> >>> Among
> >>> other things, this makes writing parsers and interpreters easier.
> >> It doesn't. Quite the opposite, in fact.
> > Oh, sorry about the misinformation, then :-s
> > Could you elaborate, please? I'm interesting in understanding how more
> > is easier from an implementor perspective. Or/and why less mode makes
> > harder.
> Every new feature may potentially need to do slightly different things
> in different modes. The semantic matrix of supporting all features in
> all modes can then easily be more complex than just adding the new
> features to a subset of the modes. It depends how difficult the
> interaction between new features and legacy modes is on average. For
> example, certain ES6 features interact rather badly with non-strict
> mode and/or web reality (e.g., block-scoped functions). Not supporting
> them there would have simplified matters.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss