excluding features from sloppy mode

David Herman dherman at mozilla.com
Fri Dec 28 13:28:42 PST 2012

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.

>>  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. 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.

>> 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.

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. 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.


More information about the es-discuss mailing list