David Herman wrote:
On Dec 28, 2012, at 12:30 PM, Brendan Eich<bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
