Le 25/02/2011 18:39, Brendan Eich a écrit :
> On Feb 25, 2011, at 7:46 AM, Mike Shaver wrote:
>> On Fri, Feb 25, 2011 at 7:36 AM, David Bruant <[email protected]>
>> wrote:
>>> Does it mean that the "use strict" directive is implicit whenever an
>>> ESHarmony feature is used? (this sounds wrong, but I'm asing the question
>>> anyway)
>> It means that the semantics of Harmony are based on ES5-strict, not
>> ES5-unstrict, yes. There will be no with, |this| will not be coerced
>> to an object wrapper, etc.
> Right.
>
> David, I wonder why you wrote that "(this sounds wrong)" about Harmony
> implying "use strict".
>
> Harmony built on ES5-strict assumes the semantics without need for a "use
> strict" as Mike noted, but there is a question of whether use strict; (with
> or without quotes) should be allowed in Harmony. We are not proposing to
> build a stricter-strict or "new strict" mode.
Being in implicit strict mode means that if someone writes some
non-strict code (so basically every web developers as of today, besides
very few people who are testing strict mode in FF4beta), this person
cannot use Harmony features without having the guarantee that code that
has previously been written is still valid.
So this person has two choices:
- Use ESHarmony features, but before that, he/she has to make sure that
code already works in strict mode
=> This is relatively ok when strict mode makes code break right away
like for the new reserved keywords or throws a SyntaxError if you were
using "with". This may lead to more subtle bugs if he/she was using
octal literals or relying on the non-strict arguments object.
Not to mention codes which rely on (function(){return this;}).call() to
return the global object.
- Not use ESHarmony features
I would tend to be more in favor of disallowing Harmony features in
non-strict code (without explicit "use strict" directive) to avoid
surprises (I'm nuancing below). In order to favor explicit over implicit.
>> I don't know, tbh, what it means for things like Proxies which can be
>> implemented in ES5 contexts and therefore be accessed by non-strict
>> code, but I would expect that their semantics (values of |this|, f.e.)
>> would match those of strict mode, however they were called.
> This is an issue in Firefox 4, I think it's just a bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=600693 (workaround is to "use
> strict" appropriately).
>
> As far as the presence of new, detectible properties such as Proxy, no opt-in
> is needed and non-strict code can detect such additions. With modules you'll
> have to opt in, but proxies at least we prototyped as JSON and other
> additions were done: the old-fashioned way. No name collisions have been
> found yet.
Indeed, when I previously mentionned "Harmony features", these can
actually be seen in two categories:
- break ECMAScript 5 strict code at a syntax level (all new syntactic
sugar additions, modules...)
- doesn't (Proxy, WeakMap, Object extensions...). As mentionned, these
may be detected, so there might be no need to imply strict mode here.
Actually, since these things are new, they could be defined by Harmony
with no mention of being in strict or non-strict mode.
(I think that it's what you meant by "no/opt-in". I'm not a native
English speaker, I'm not entirely sure of the meaning)
So I would be in favor of imposing explicit strict mode before being
allowed to use ES5-syntax breaking features.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
