Andreas Rossberg wrote:
On 29 December 2012 14:51, Axel Rauschmayer<[email protected]> wrote:
I’m sympathetic to both sides of this argument. How would you handle things?
Ideally? Backing out of the whole 1JS marketing maneuver?
It's not just marketing surface, but lack of version= substance. How do
you propose backing out of that? Defining RFC4329 application/javascript
and application/ecmascript ;version= parameter values and telling people
to write script tags using those types?
In the long
run, I see it as more harmful than helpful, as it inevitably leads to
complexity creep, subtle mode mixtures,
Note the V8 team (via MarkM) rightly prefigured 1JS by asking for "no
more modes" several years ago. Now you want explicit modes? The world
turns...
and refactoring hazards that
are there to stay for eternity. Instead, just make all new features
strict-mode only and be done with it.
Let's be clear about the refactoring hazards. They do not involve early
errors. So the only issues are the runtime semantic changes:
* The arguments object in a strict function not aliasing formal parameters.
* Poison pill properties on strict function objects.
* Anything else I'm forgetting.
Is this really that bad in the way of refactoring hazards? Anyone
refactoring from old to ES6 or later code should get rid of arguments.
The poison pill properties may be needed so that means don't refactor
this function, leave it in sloppy mode using function syntax.
What's the big hazard I'm missing?
But I've accepted that I am in the minority with that opinion, and
it's too late anyway. Short of that, at least hold the line with
modules as the only implicit opt-in.
There's a case for class bodies as implicitly strict, you can't dismiss
it with generalities about refactoring hazards in my book :-P. Care to
deal with the specific pro-strict-class argument?
But in reality I'm pretty sure
that we will give in to extending the list at some point, if not in
ES6 then in ES7.
I say all new forms with distinct heads and code-bearing bodies should
be strict-only.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
