excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Fri Dec 28 14:21:41 PST 2012


David Herman wrote:
> On Dec 28, 2012, at 12:30 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>
>>> But even if*not*, it's not worth proliferating the number of cases that are implicitly strict.
>> To answer that, you have to speculate on costs and benefits of strict mode for classes outside of modules, not talk about modules more:
>
> 'scuse me for living! ;) I was making a contrast: what's good about modules -- that they are coarse-grained -- is not the case for classes.

Point taken, but if we are exploring alternative futures, one you do not 
want but concede may happen (classes spread outside of modules), we 
should stick to the path of exploration we're on. Otherwise it seems 
like you're backing up above that multiverse branch point and arguing 
for modules prevailing!


>>>   Modules are a good place to implicitly opt in to strict mode, because they're a coarse-grained program structuring feature.
>> And granularity of class vs. module can't matter under the "even if *not*" hypothesis we are exploring together in this branch of future-reality:
>
> Yes, it can. Let's postulate that modules are a total failure. In addition to my being driven to the drink and moving to Zihuatanejo to run a small beachside hotel, we've failed to use modules as a carrot to bring people to strict mode.

A bit extreme, but ok (I'll bartend :-P).

>   Then in that future, I claim that trying additionally to bring people to strict mode by one or more finer-grained mechanisms will not be worth it. It will lead to code that is sometimes strict, sometimes not, and often mixed; and it will lead to a more confusing set of policies that programmers will have to (but often fail to) memorize.

That's the sticking point. Is that likely greater confusion still not 
worth the rising tide of strictness, under the classes-prevail 
hypothesis? I'm not twisting your arm. It could be not worth it. But 
couldn't it (if classes predominate) win?

>
>>> Classes are finer-grained, especially dynamic classes like in ES6.
>> The question really is, why have sloppy-mode classes at all? Who wants or needs them?
>
> That's easy. If you're programming in sloppy mode, you still want classes. Whether they're strict code is simply less important than whether they exist at all.

Brandon addressed this. Anyone mixing sloppy and strict (which will 
become more common as libraries "use strict") has to take care already. 
You don't know the full call graph, so callees from sloppy code could be 
strict.

I also disagree that the (uncontroversial) importance of classes 
existing and being usable from sloppy mode trumps the importance of 
whether classes are strict by fiat. First, everyone wants classes 
available in sloppy mode, even Mark. In that light, the importance of 
classes from sloppy mode is invariant "ground" and we're arguing about 
the "figure": whether classes should be strict by fiat.

Second, if classes' strictness in ES6 is unimportant in absolute terms 
we don't need "use strict"; in ClassElement syntax. Yet strictness helps 
avoid duplicate formals, eval and arguments rebinding/shadowing, and 
other chestnuts that cannot matter to sloppy consumers of classes. Only 
the implementor of the class-in-sloppy-mode could use such features. 
They're "callee-side".

So again: why would we want to make such bad old forms possible in brand 
new (albeit embedded in sloppy code) classes?

Relative importance doesn't help answer this. My answer is that we do 
not want bad old slop in classes.

> Here's another way to put my argument. Let's say you write a program that isn't using modules but is 80% full of classes. I argue that's not reaching 80% of the goal of writing strict code. It's a Pyrrhic almost-victory for strict mode: a confusing mixture of implicitly strict and implicitly sloppy code.

This is indeed the sticking point.

I call it 80% better than nothing, and I further predict modules won't 
get to 100 or even 99% soon, and even ignoring new ES6 features, 
developers will face a mix of strict and slopppy code.

Then the game is momentum and secular up-trend in strict code. In that 
game, strict-by-fiat is strictly (heh) better.

>   There's a difference in kind here, not just degree: a module is very strongly delimited from other code (especially when it occurs in a separate file), whereas a class always intermingles with other code.

What do you mean by "intermingle"? See above about caller vs. strict 
callee. There's no difference that I can see in either source delimiting 
or runtime caller/callee combinatorics between modules (with function 
exports) and classes (with methods).

/be


More information about the es-discuss mailing list