>> So I think it might be a little misleading to say Harmony is strict-only.
>
> Who ever said that? :-P
Yikes... not playing who-said-what. For whatever reason, Waldemar got the
impression that someone said it, and I'm correcting the misconception, that's
all.
> I've written that Harmony is b
On Mar 3, 2011, at 6:55 PM, David Herman wrote:
> So I think it might be a little misleading to say Harmony is strict-only.
Who ever said that? :-P
I've written that Harmony is based on ES5 strict. But even ES5 strict code can
call non-strict code. Same goes for Harmony. It's a big shared-heap
On Mar 3, 2011, at 5:33 PM, Waldemar Horwat wrote:
> If we're saying that Harmony is strict-only, settable by a tag, what
> will indirect eval and the Function constructor do if the evaluated code
> doesn't start with a "use strict" directive?
Yeah, "strict-only" is probably not quite the righ
On 02/25/11 13:26, Brendan Eich wrote:
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
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)
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
> On 2/25/11 4:08 PM, David Bruant wrote:
>> 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).
>
> I was under the impressi
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
> On 2/25/11 4:08 PM, David Bruant wrote:
>> 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).
>
> I was under the impressio
On 2/25/11 4:08 PM, David Bruant wrote:
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).
I was under the impression that Harmony features would only be allowed
for scripts that
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
>> 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 qu
On Feb 25, 2011, at 9:39 AM, Brendan Eich wrote:
> 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
On Feb 25, 2011, at 7:46 AM, Mike Shaver wrote:
> On Fri, Feb 25, 2011 at 7:36 AM, David Bruant
> 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 semantic
On Fri, Feb 25, 2011 at 7:36 AM, David Bruant 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.
Hi,
I have once seen a presentation from Douglas Crockford where he was
saying that new ECMAScript features would be developed on top of ES
strict mode (sorry for not having the exact quote, I hope I'm not
misinterpreting). I have re-read that "Harmony is a super-set of ES5
stri
12 matches
Mail list logo
