excluding features from sloppy mode
axel at rauschma.de
Sun Dec 30 12:39:29 PST 2012
>> - Pro 1JS: You can use new stuff everywhere.
>> - Contra 1JS: You can’t use all of the new stuff. There are tricky exceptions and rules.
> Check me: I think the only exceptions that we have found are let and function-in-block. At the last TC39 meeting, we resolved to try reserving let contextually in sloppy code. Results not yet in on that front, so by the book, following our own process, we should get some more data.
> Function-in-block is indeed a problem without evangelization. But Mark said he was game. I don't know how much Google, Microsoft, Apple, and Mozilla can do to evangelize f-i-b content owners (if any are still around and actively maintaining) to switch from non-ES6 to ES6 f-i-b semantics, but that is also something we could try.
> If we get past these two, then we're in the winning "Pro 1JS" / "If you want the new stuff, just use it" scenario.
Thanks! Good points.
The slogan thing may be a bit simplistic, but I do think it matters, because it implies a clear strategy (not necessarily the other way around). And “If you want the new stuff, just use it [wherever – independently of the mode you are currently in]” sounds good to me. If there really are no exceptions to this rule then that is awesome.
> You're getting ahead of reality here.
Absolutely. And my intention is not to fight reality (even if it sometimes might come across that way), but to get a general sense of a long-term direction. Often valid reasons stand in the way of some of the more idealistic visions, but I still think it helps to discuss them. At least it helps me understand what’s going on.
If 1JS works out, we’ll continue to have a random mix of strict and non-strict code, right?
But then why not make it a long-term goal to eliminate the difference between strict and non-strict? What is the main impediment to that? Perhaps the different value of `this` in non-method functions. Checking the value of `this` is sometimes used to check whether a function has been invoked as a method or as a non-method function. So maybe it makes sense to introduce another way of enforcing a certain way of invocation. Everything else that is non-strict should disappear over time (right?).
> Consider that no static code mode can tame implicit conversions, which strict mode leaves intact apart from removing |this| wrapping of primitives. Implicit conversions happen on values that can flow anywhere, including references to objects in the heap. There's no static strict/sloppy partitioning.
> Implicit conversions remain the biggest WTF source. To tame them I think we need to work on value objects and beyond. This is nowhere in sight for ES6.
As it stands, ES6 is great (independently of 1JS or not), already. I made a list of the 10 biggest JS pitfalls and most of them will be gone under ES6. Much less to worry about, much easier to learn.
That doesn’t mean I’m not looking forward to value objects, though. ;-)
Dr. Axel Rauschmayer
axel at rauschma.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss