excluding features from sloppy mode
rossberg at google.com
Sun Dec 30 01:58:12 PST 2012
On 29 December 2012 22:11, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>> On 29 December 2012 14:51, Axel Rauschmayer<axel at rauschma.de> wrote:
>>> I’m sympathetic to both sides of this argument. How would you handle
>> Ideally? Backing out of the whole 1JS marketing maneuver?
> It's not just marketing surface, but lack of version= substance. How do you
> application/ecmascript ;version= parameter values and telling people to
> write script tags using those types?
As I said: make everything available in strict mode.
>> 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...
I'm sure no one had the current state of affairs in mind. My argument
is (and has been a year ago), that factually, 1JS means _more_ modes
(which is why I called the 1JS tag "marketing"). And that _is_
I wish I had made a list, but IIRC over the last few meetings we have
spend a significant and increasing amount of time discussing problems
with new features and sloppy mode interaction. You can brush that off
as being only spec or implementation complexity. But I disagree. Any
spec complexity will also be user-facing complexity too at some point,
e.g. if your program does not work as expected.
> 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.
I'm surprised you're asking this, because you have pointed out
repeatedly in previous meetings that there are serious hazards. ;)
> 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?
It's complexity creep. I don't think we will stop there. Boiling the frog.
[Sorry for being brief, but I'm off to a 2-week trip in about 2 hours
and haven't packed yet :). I'll be off-line during that time, btw, so
unfortunately won't be able to follow the discussion further.]
More information about the es-discuss