A new function name property proposal

[Brandon Benvie]

This is based on
http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions

Justification: the usefulness of the name of function is not just for
debugging. It is useful in the same ways that property names as strings are
such as dispatching by name or assigning by name.

The goals expand a bit beyond the ones in the strawman, and are also
updated based on the current state of affairs. The first goal is that every
function has an own "name" property, and this property is always a string
(unless the user specifically decides to violate this norm), and that this
name property is initialized with the value that makes sense from static
semantics.The third goal is to allow predefined names to be altered in
cases where it makes sense.

Semantics:

The baseline for every function is the 'name' property defined as
{ value: "",
  writable: true,
  enumerable: false,
  configurable: false }.

For FunctionDeclarations, named FunctionExpressions, MethodDefinitions, or
accessor Properties then the function's "name" property is set to the given
identifier. In the case of the constructor method of classes, the class
name is used instead. In the case of accessors, 'get ' or 'set ' is
included. The "name" property is set to non-writable. Function.prototype's
name is also non-writable.

Anonymous FunctionExpressions and ArrowFunctionExpressions assigned in a
VariableDeclaration or ObjectExpression are given the name of the variable
or property they are assigned to and the name remains writable. Anonymous
ClassExpressions follow the same semantics, with the name being used for
the constructor method.

Whenever a function's name is defined by a Symbol instead of a regular
identifier then the name is the result of ToString(symbol).

The name property should (probably) not have any reflection on the output
of Function.prototype.toString.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Allen Wirfs-Brock]

On Nov 15, 2012, at 4:44 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Nov 15, 2012, at 4:17 PM, Brendan Eich wrote:
>> 
>>> Of course, 'let' short for 'letter' :-|.
>>> 
>>> Contextual keyword with [no LineTerminator here] after sounds like the 
>>> plan. I'm curious whether you have already implemented this in Traceur?
>>> 
>>> /be
>> 
>> I wonder if the [no LineTerminator here] is really need in practice?
>> 
>> How often does
>> 
>> /* whatever*/  ;
>> let
>>   x = "abc";
>> 
>> actually occur in real code??
> 
> Who knows? We can chance it but should we? Optimize by daring fate, 
> prototyping and spec'ing in draft-ES6, and if we get bad news late in the 
> process, change course. I like it if the optimization wins. If it loses

Another experiment would tell us more...and as Peter points out, there are 
people who like to put their declarator keyword on a separate line. 



> 
>> (I'm assuming that the JSC test was just making "let" a reserved id rather 
>> than a contextual keyword)
> 
> Right.
> 
> /be
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

"use strict" is removed from code by default ... this is where it goes once
minified: nowhere.

I would rather force a minifier explicitly to remove it rather than force
it to keep it for ES5 ... also ES5 is not use strict so I don't get this
Closure Compiler choice.

I don't see minified code with "use strict" that often


On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich  wrote:

> Andrea Giammarchi wrote:
>
>> Said that, I would rather force removal of "use strict" 'cause if there
>> is explicit desire from the developer. Isn't it?
>>
>
> What do you mean? "use strict" is not going away. It is used by some
> developers. I had a show of hands at JSConf.au, definitely a minority but
> significant.
>
> You are barking up the wrong tree. And Angus's abuses of 'with' are
> unjustified. Yes, "be water". Yes, masters may break rules students must
> follow. None of that philosophizing justifies 'with' abusage or
> repealing/undoing "use strict".
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Brendan Eich]

Allen Wirfs-Brock wrote:

On Nov 15, 2012, at 4:17 PM, Brendan Eich wrote:


Of course, 'let' short for 'letter' :-|.

Contextual keyword with [no LineTerminator here] after sounds like the plan. 
I'm curious whether you have already implemented this in Traceur?

/be


I wonder if the [no LineTerminator here] is really need in practice?

How often does

 /* whatever*/  ;
 let
   x = "abc";

actually occur in real code??


Who knows? We can chance it but should we? Optimize by daring fate, 
prototyping and spec'ing in draft-ES6, and if we get bad news late in 
the process, change course. I like it if the optimization wins. If it 
loses



(I'm assuming that the JSC test was just making "let" a reserved id rather than 
a contextual keyword)


Right.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Peter van der Zee]

On Fri, Nov 16, 2012 at 1:35 AM, Allen Wirfs-Brock
 wrote:
>
> On Nov 15, 2012, at 4:17 PM, Brendan Eich wrote:
>
>> Of course, 'let' short for 'letter' :-|.
>>
>> Contextual keyword with [no LineTerminator here] after sounds like the plan. 
>> I'm curious whether you have already implemented this in Traceur?
>>
>> /be
>
> I wonder if the [no LineTerminator here] is really need in practice?
>
> How often does
>
> /* whatever*/  ;
> let
>   x = "abc";
>
> actually occur in real code??

Um, if that's a concern, I often see multiple var declarations start
with a newline after var, to line up all the variable names (including
the first)...

var
  foo=1,
  bar=2,
  zee=...;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Brendan Eich]

Andrea Giammarchi wrote:
Said that, I would rather force removal of "use strict" 'cause if 
there is explicit desire from the developer. Isn't it?


What do you mean? "use strict" is not going away. It is used by some 
developers. I had a show of hands at JSConf.au, definitely a minority 
but significant.


You are barking up the wrong tree. And Angus's abuses of 'with' are 
unjustified. Yes, "be water". Yes, masters may break rules students must 
follow. None of that philosophizing justifies 'with' abusage or 
repealing/undoing "use strict".


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Allen Wirfs-Brock]

On Nov 15, 2012, at 4:17 PM, Brendan Eich wrote:

> Of course, 'let' short for 'letter' :-|.
> 
> Contextual keyword with [no LineTerminator here] after sounds like the plan. 
> I'm curious whether you have already implemented this in Traceur?
> 
> /be

I wonder if the [no LineTerminator here] is really need in practice?

How often does

/* whatever*/  ;
let
  x = "abc";

actually occur in real code??

(I'm assuming that the JSC test was just making "let" a reserved id rather than 
a contextual keyword)

Allen







> 
> Erik Arvidsson wrote:
>> On Thu, Nov 15, 2012 at 2:49 PM, Allen Wirfs-Brock > > wrote:
>> 
>> 
>>This is what TC39 agreed to try when we started down the 1JS path,
>>with the expectation that implementation would explore the
>>compatibility impact.
>> 
>> 
>> JSC tried making let a keyword and it broke things, forcing them to revert 
>> that.
>> 
>> http://trac.webkit.org/changeset/113352
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Brendan Eich]

Oliver Hunt wrote:
Even if they weren't .caller is insufficient: it can't walk over 
strict, native, or global code that exists in the call stack, so at 
best you only get a crappy result.


Note that .caller references a function, not an activation, so it can't 
backtrace recursive call stacks.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Brendan Eich]

Of course, 'let' short for 'letter' :-|.

Contextual keyword with [no LineTerminator here] after sounds like the 
plan. I'm curious whether you have already implemented this in Traceur?


/be

Erik Arvidsson wrote:
On Thu, Nov 15, 2012 at 2:49 PM, Allen Wirfs-Brock 
mailto:al...@wirfs-brock.com>> wrote:



This is what TC39 agreed to try when we started down the 1JS path,
with the expectation that implementation would explore the
compatibility impact.


JSC tried making let a keyword and it broke things, forcing them to 
revert that.


http://trac.webkit.org/changeset/113352
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

"by default" as if it's there there must be a reason since, as Oliver
pointed, is changing program behavior once removed.

I would expect closure compiler to be smart enough to understand strictness
and dafine it once in the most outer scope or grouping them but actually
with gzip this is not such big problem.

Said that, I would rather force removal of "use strict" 'cause if there is
explicit desire from the developer. Isn't it?


On Thu, Nov 15, 2012 at 2:58 PM, ๏̯͡๏ Jasvir Nagra  wrote:

>
>
> Jasvir Nagra
>
>
>
> On Thu, Nov 15, 2012 at 1:43 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> have to dig about the Engines problems, I assumed it was a matter of
>> "hey, I am your parent caller" pointer and nothing else.
>>
>> Said that, you want a use case, here:
>> https://github.com/WebReflection/poo/blob/master/src/superable.js
>>
>> This let you make any object superable so that you can access
>> this.super() as it is specified in ES6 (without this. but that's not
>> convenient to pollute the global scope with a "super" getter and without a
>> context) without impacting performance at all unless the method is
>> accessing that super. In latter case yes, you have a performance impact and
>> it's going to be probably slower than other solutions but it's about having
>> everything else at the same speed except when you do need super access and
>> not every time you call a method.
>>
>> More over, you don't need a central uniq entry point to share superable
>> so that different libraries could extend each other without problems.
>>
>> This is not possible if the code is under use strict directive, this is
>> why I had to update also require_client to force all code to be evaluated
>> without that directive once minified:
>> https://github.com/WebReflection/require_client
>>
>> About minifiers, Google Closure compiler and YUI are only two examples
>> ... do you know anyone better than these two that by default does not
>> change the "use strict" behavior? That would be nice to know, thanks.
>>
>
> I am not sure why "by default" matters.  Closure compiler takes a flag
> --language_in=ECMASCRIPT5_STRICT and preserves strictness.
>
> br
>>
>>
>> On Thu, Nov 15, 2012 at 1:16 PM, David Herman wrote:
>>
>>> On Nov 15, 2012, at 1:15 PM, David Herman  wrote:
>>>
>>> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock 
>>> wrote:
>>> >
>>> >> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
>>> >>
>>> >>> I believe with is much more problematic than caller for all Engines
>>> out there. A reference to "who is invoking" cannot be that bad ... is it?
>>> >>
>>> >> Yes it is!  It is a capability leak.  It give a callee access to
>>> functions that would otherwise be inaccessible to the callee.  Who knows
>>> what mischief can be accomplished by calling such functions.
>>> >
>>> > What's more, it's totally inadequate as a stack walking tool. If any
>>> function appears twice in a call stack (most commonly in the presence of
>>> recursion), you can't walk the whole stack. You either have to detect the
>>> repeat and give up, or loop infinitely. So in addition to being a security,
>>> performance, and engineering nightmare, arguments.caller is pretty much
>>> useless.
>>>
>>> And to be clear, it *is* a problem for engines: it prevents proper tail
>>> calls (or even tail call optimization).
>>>
>>> Dave
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[๏̯͡๏ Jasvir Nagra]

Jasvir Nagra



On Thu, Nov 15, 2012 at 1:43 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> have to dig about the Engines problems, I assumed it was a matter of "hey,
> I am your parent caller" pointer and nothing else.
>
> Said that, you want a use case, here:
> https://github.com/WebReflection/poo/blob/master/src/superable.js
>
> This let you make any object superable so that you can access this.super()
> as it is specified in ES6 (without this. but that's not convenient to
> pollute the global scope with a "super" getter and without a context)
> without impacting performance at all unless the method is accessing that
> super. In latter case yes, you have a performance impact and it's going to
> be probably slower than other solutions but it's about having everything
> else at the same speed except when you do need super access and not every
> time you call a method.
>
> More over, you don't need a central uniq entry point to share superable so
> that different libraries could extend each other without problems.
>
> This is not possible if the code is under use strict directive, this is
> why I had to update also require_client to force all code to be evaluated
> without that directive once minified:
> https://github.com/WebReflection/require_client
>
> About minifiers, Google Closure compiler and YUI are only two examples ...
> do you know anyone better than these two that by default does not change
> the "use strict" behavior? That would be nice to know, thanks.
>

I am not sure why "by default" matters.  Closure compiler takes a flag
--language_in=ECMASCRIPT5_STRICT and preserves strictness.

br
>
>
> On Thu, Nov 15, 2012 at 1:16 PM, David Herman  wrote:
>
>> On Nov 15, 2012, at 1:15 PM, David Herman  wrote:
>>
>> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock 
>> wrote:
>> >
>> >> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
>> >>
>> >>> I believe with is much more problematic than caller for all Engines
>> out there. A reference to "who is invoking" cannot be that bad ... is it?
>> >>
>> >> Yes it is!  It is a capability leak.  It give a callee access to
>> functions that would otherwise be inaccessible to the callee.  Who knows
>> what mischief can be accomplished by calling such functions.
>> >
>> > What's more, it's totally inadequate as a stack walking tool. If any
>> function appears twice in a call stack (most commonly in the presence of
>> recursion), you can't walk the whole stack. You either have to detect the
>> repeat and give up, or loop infinitely. So in addition to being a security,
>> performance, and engineering nightmare, arguments.caller is pretty much
>> useless.
>>
>> And to be clear, it *is* a problem for engines: it prevents proper tail
>> calls (or even tail call optimization).
>>
>> Dave
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Erik Arvidsson]

On Thu, Nov 15, 2012 at 2:49 PM, Allen Wirfs-Brock wrote:

>
> This is what TC39 agreed to try when we started down the 1JS path, with
> the expectation that implementation would explore the compatibility impact.
>

JSC tried making let a keyword and it broke things, forcing them to revert
that.

http://trac.webkit.org/changeset/113352
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

have to dig about the Engines problems, I assumed it was a matter of "hey,
I am your parent caller" pointer and nothing else.

Said that, you want a use case, here:
https://github.com/WebReflection/poo/blob/master/src/superable.js

This let you make any object superable so that you can access this.super()
as it is specified in ES6 (without this. but that's not convenient to
pollute the global scope with a "super" getter and without a context)
without impacting performance at all unless the method is accessing that
super. In latter case yes, you have a performance impact and it's going to
be probably slower than other solutions but it's about having everything
else at the same speed except when you do need super access and not every
time you call a method.

More over, you don't need a central uniq entry point to share superable so
that different libraries could extend each other without problems.

This is not possible if the code is under use strict directive, this is why
I had to update also require_client to force all code to be evaluated
without that directive once minified:
https://github.com/WebReflection/require_client

About minifiers, Google Closure compiler and YUI are only two examples ...
do you know anyone better than these two that by default does not change
the "use strict" behavior? That would be nice to know, thanks.

br


On Thu, Nov 15, 2012 at 1:16 PM, David Herman  wrote:

> On Nov 15, 2012, at 1:15 PM, David Herman  wrote:
>
> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock 
> wrote:
> >
> >> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
> >>
> >>> I believe with is much more problematic than caller for all Engines
> out there. A reference to "who is invoking" cannot be that bad ... is it?
> >>
> >> Yes it is!  It is a capability leak.  It give a callee access to
> functions that would otherwise be inaccessible to the callee.  Who knows
> what mischief can be accomplished by calling such functions.
> >
> > What's more, it's totally inadequate as a stack walking tool. If any
> function appears twice in a call stack (most commonly in the presence of
> recursion), you can't walk the whole stack. You either have to detect the
> repeat and give up, or loop infinitely. So in addition to being a security,
> performance, and engineering nightmare, arguments.caller is pretty much
> useless.
>
> And to be clear, it *is* a problem for engines: it prevents proper tail
> calls (or even tail call optimization).
>
> Dave
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[David Herman]

On Nov 15, 2012, at 1:15 PM, David Herman  wrote:

> On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock  wrote:
> 
>> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
>> 
>>> I believe with is much more problematic than caller for all Engines out 
>>> there. A reference to "who is invoking" cannot be that bad ... is it?
>> 
>> Yes it is!  It is a capability leak.  It give a callee access to functions 
>> that would otherwise be inaccessible to the callee.  Who knows what mischief 
>> can be accomplished by calling such functions.
> 
> What's more, it's totally inadequate as a stack walking tool. If any function 
> appears twice in a call stack (most commonly in the presence of recursion), 
> you can't walk the whole stack. You either have to detect the repeat and give 
> up, or loop infinitely. So in addition to being a security, performance, and 
> engineering nightmare, arguments.caller is pretty much useless.

And to be clear, it *is* a problem for engines: it prevents proper tail calls 
(or even tail call optimization).

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[David Herman]

On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock  wrote:

> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
> 
>> I believe with is much more problematic than caller for all Engines out 
>> there. A reference to "who is invoking" cannot be that bad ... is it?
> 
> Yes it is!  It is a capability leak.  It give a callee access to functions 
> that would otherwise be inaccessible to the callee.  Who knows what mischief 
> can be accomplished by calling such functions.

What's more, it's totally inadequate as a stack walking tool. If any function 
appears twice in a call stack (most commonly in the presence of recursion), you 
can't walk the whole stack. You either have to detect the repeat and give up, 
or loop infinitely. So in addition to being a security, performance, and 
engineering nightmare, arguments.caller is pretty much useless.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[David Herman]

On Nov 15, 2012, at 12:32 PM, Andrea Giammarchi  
wrote:

> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you don't 
> mind and you are not already otherwise I'll stop here.

Oliver works for Apple on JSC and is a representative of Apple on TC39.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[David Herman]

On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi  
wrote:

> Can we just stick with the answer if it is planned or not?

It's not. "use strict" cannot be disabled, by design.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Allen Wirfs-Brock]

On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:

> I believe with is much more problematic than caller for all Engines out 
> there. A reference to "who is invoking" cannot be that bad ... is it?

Yes it is!  It is a capability leak.  It give a callee access to functions that 
would otherwise be inaccessible to the callee.  Who knows what mischief can be 
accomplished by calling such functions.

Allen





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

Strict mode has substantial semantic impact, any minifier that is removing it 
is changing program behaviour, potentially dramatically.  If you're okay with 
the minifier disabling strict mode you should not be developing with strict 
mode at all, as it will mean your development builds will potentially have 
different behaviour from what you're deploying, as an argument for "no strict", 
this makes no sense.

And yes adding an additional closure and call to every function is going to 
adversely impact performance, but why are you doing that in the first place?  
If you're using .caller for debugging it's unnecessary in production, so the 
performance hit won't be there when it matters.

So far you haven't given any real use-case where arguments.caller is a) better 
than the built in functionality, and b) actually necessary in production builds.

--Oliver

On Nov 15, 2012, at 12:45 PM, Andrea Giammarchi  
wrote:

> function wrappers created to simulate caller are obviously slower. 2 calls, 
> the wrap and the wrapped, 1 extra nested scope, and 2 callers, since these 
> will run no strict in any case. A de-coupled entry point to reach a caller 
> could easily speed up performance a lot ... then you have to explain to 
> developers that even if they think they are writing with "use strict" they 
> are not since after minification that directive will be most likely gone so 
> they have zero gain except while writing/testing non production code before 
> minification (here those tools you mentioned can be useful for strict 
> behaviors, not after on real world, IMHO)
> 
> br
> 
> 
> On Thu, Nov 15, 2012 at 12:38 PM, Oliver Hunt  wrote:
> 
> On Nov 15, 2012, at 12:33 PM, Andrea Giammarchi  
> wrote:
> 
>> also, take a break if you have time and enjoy this talk: 
>> http://www.youtube.com/watch?v=MFtijdklZDo
>> 
>> 
>> On Thu, Nov 15, 2012 at 12:32 PM, Andrea Giammarchi 
>>  wrote:
>> funny, 'cause at least one use case I have implemented, is about improving 
>> performances at least 2X for 99% of OOP frameworks out there ... I guess you 
>> like function wrappers then to simulate caller when needed, right?
>> 
>> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you don't 
>> mind and you are not already otherwise I'll stop here.
> 
> You mean a TC39 member like me?
> 
> If you have specific examples, you can file bugs on the various engines where 
> the performance hit is excessive (2x obviously being excessive).
> 
> --Oliver
> 
> 
>> 
>> br
>> 
>> 
>> On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt  wrote:
>> 
>> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi 
>>  wrote:
>> 
>>> the debugger you mention is most likely using the with statement ... 
>> 
>> No, the debugger is part of the virtual machine.  I'm aware that the WebKit 
>> inspector currently has a rather annoying bug wrt executing code in strict 
>> mode, but that's a _bug_.
>> 
>>> 
>>> Can we just stick with the answer if it is planned or not? I don't want to 
>>> convince you that there are cases where non strict features are needed ... 
>>> it is just like that and many times already discussed.
>> 
>> Not planned.
>> 
>>> Again, is there any real reason to not consider a "no strict" directive? 
>>> The whole web is running no strict thanks to minifiers so I really would 
>>> like to listen to real reasons over already discussed academic debates.
>> 
>> Because it would complicate the language, the implementation, and have 
>> negative performance consequences.
>> 
>> --Oliver
>> 
>>> 
>>> 
>>> 
>>> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
>>> 
>>> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi 
>>>  wrote:
>>> 
 my typo ... I am NOT talking about callee, I am talking about caller which 
 is NOT a misfeature specially when it comes to debug and stack trace.
>>> 
>>> The solution to debugging is to use a debugger, not to try and debug from 
>>> within the language.
>>> 
>>> All modern JS engines provide a) a debugger and b) stack traces on 
>>> exceptions.
>>> 
>>> Even if they weren't .caller is insufficient: it can't walk over strict, 
>>> native, or global code that exists in the call stack, so at best you only 
>>> get a crappy result.
>>> 
>>> Like I said in my prior email: If you're willing to toss out the 
>>> improvements of strict mode just to get arguments.caller, you may as well 
>>> stop using it in the first place.
>>> 
>>> --Oliver
>>> 
 
 
 On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
 
 On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi 
  wrote:
 
 > I wonder if there is any plan to allow a chunk of code to disable for 
 > its own closure purpose a previously called "use strict"; directive.
 >
 > This is about the ability to use, when not possible otherwise, some good 
 > old feature such caller which is impossible to replicate when use strict 
 > is in place.
 >
 > I am talking about arguments.callee, I am talking about calle

Re: "no strict"; directive

[Andrea Giammarchi]

function wrappers created to simulate caller are obviously slower. 2 calls,
the wrap and the wrapped, 1 extra nested scope, and 2 callers, since these
will run no strict in any case. A de-coupled entry point to reach a caller
could easily speed up performance a lot ... then you have to explain to
developers that even if they think they are writing with "use strict" they
are not since after minification that directive will be most likely gone so
they have zero gain except while writing/testing non production code before
minification (here those tools you mentioned can be useful for strict
behaviors, not after on real world, IMHO)

br


On Thu, Nov 15, 2012 at 12:38 PM, Oliver Hunt  wrote:

>
> On Nov 15, 2012, at 12:33 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> also, take a break if you have time and enjoy this talk:
> http://www.youtube.com/watch?v=MFtijdklZDo
>
>
> On Thu, Nov 15, 2012 at 12:32 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> funny, 'cause at least one use case I have implemented, is about
>> improving performances at least 2X for 99% of OOP frameworks out there ...
>> I guess you like function wrappers then to simulate caller when needed,
>> right?
>>
>> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you
>> don't mind and you are not already otherwise I'll stop here.
>>
>
> You mean a TC39 member like me?
>
> If you have specific examples, you can file bugs on the various engines
> where the performance hit is excessive (2x obviously being excessive).
>
> --Oliver
>
>
>
>> br
>>
>>
>> On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt  wrote:
>>
>>>
>>> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> the debugger you mention is most likely using the with statement ...
>>>
>>>
>>> No, the debugger is part of the virtual machine.  I'm aware that the
>>> WebKit inspector currently has a rather annoying bug wrt executing code in
>>> strict mode, but that's a _bug_.
>>>
>>>
>>> Can we just stick with the answer if it is planned or not? I don't want
>>> to convince you that there are cases where non strict features are needed
>>> ... it is just like that and many times already discussed.
>>>
>>>
>>> Not planned.
>>>
>>> Again, is there any real reason to not consider a "no strict" directive?
>>> The whole web is running no strict thanks to minifiers so I really would
>>> like to listen to real reasons over already discussed academic debates.
>>>
>>>
>>> Because it would complicate the language, the implementation, and have
>>> negative performance consequences.
>>>
>>> --Oliver
>>>
>>>
>>>
>>>
>>> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
>>>

 On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi <
 andrea.giammar...@gmail.com> wrote:

 my typo ... I am NOT talking about callee, I am talking about caller
 which is NOT a misfeature specially when it comes to debug and stack trace.


 The solution to debugging is to use a debugger, not to try and debug
 from within the language.

 All modern JS engines provide a) a debugger and b) stack traces on
 exceptions.

 Even if they weren't .caller is insufficient: it can't walk over
 strict, native, or global code that exists in the call stack, so at best
 you only get a crappy result.

 Like I said in my prior email: If you're willing to toss out the
 improvements of strict mode just to get arguments.caller, you may as well
 stop using it in the first place.

 --Oliver



 On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:

>
> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> > I wonder if there is any plan to allow a chunk of code to disable
> for its own closure purpose a previously called "use strict"; directive.
> >
> > This is about the ability to use, when not possible otherwise, some
> good old feature such caller which is impossible to replicate when use
> strict is in place.
> >
> > I am talking about arguments.callee, I am talking about caller.
>
> arguments.callee and .caller are not good features.
>
> Being able to access your caller is a misfeature.
>
> arguments.callee is simply unnecessary.
>
> Also having the ability to lose strict semantics at arbitrary
> locations in the middle of other strict modes makes things even slower, 
> and
> adds all sorts of weird semantic behaviours (eg. what would eval('"no
> strict"; var x;') do? -- this is hypothetical, just given as a trivial
> example of where things go weird)
>
> --Oliver
>



>>>
>>>
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

On Nov 15, 2012, at 12:33 PM, Andrea Giammarchi  
wrote:

> also, take a break if you have time and enjoy this talk: 
> http://www.youtube.com/watch?v=MFtijdklZDo
> 
> 
> On Thu, Nov 15, 2012 at 12:32 PM, Andrea Giammarchi 
>  wrote:
> funny, 'cause at least one use case I have implemented, is about improving 
> performances at least 2X for 99% of OOP frameworks out there ... I guess you 
> like function wrappers then to simulate caller when needed, right?
> 
> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you don't 
> mind and you are not already otherwise I'll stop here.

You mean a TC39 member like me?

If you have specific examples, you can file bugs on the various engines where 
the performance hit is excessive (2x obviously being excessive).

--Oliver


> 
> br
> 
> 
> On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt  wrote:
> 
> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi  
> wrote:
> 
>> the debugger you mention is most likely using the with statement ... 
> 
> No, the debugger is part of the virtual machine.  I'm aware that the WebKit 
> inspector currently has a rather annoying bug wrt executing code in strict 
> mode, but that's a _bug_.
> 
>> 
>> Can we just stick with the answer if it is planned or not? I don't want to 
>> convince you that there are cases where non strict features are needed ... 
>> it is just like that and many times already discussed.
> 
> Not planned.
> 
>> Again, is there any real reason to not consider a "no strict" directive? The 
>> whole web is running no strict thanks to minifiers so I really would like to 
>> listen to real reasons over already discussed academic debates.
> 
> Because it would complicate the language, the implementation, and have 
> negative performance consequences.
> 
> --Oliver
> 
>> 
>> 
>> 
>> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
>> 
>> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi 
>>  wrote:
>> 
>>> my typo ... I am NOT talking about callee, I am talking about caller which 
>>> is NOT a misfeature specially when it comes to debug and stack trace.
>> 
>> The solution to debugging is to use a debugger, not to try and debug from 
>> within the language.
>> 
>> All modern JS engines provide a) a debugger and b) stack traces on 
>> exceptions.
>> 
>> Even if they weren't .caller is insufficient: it can't walk over strict, 
>> native, or global code that exists in the call stack, so at best you only 
>> get a crappy result.
>> 
>> Like I said in my prior email: If you're willing to toss out the 
>> improvements of strict mode just to get arguments.caller, you may as well 
>> stop using it in the first place.
>> 
>> --Oliver
>> 
>>> 
>>> 
>>> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>>> 
>>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi 
>>>  wrote:
>>> 
>>> > I wonder if there is any plan to allow a chunk of code to disable for its 
>>> > own closure purpose a previously called "use strict"; directive.
>>> >
>>> > This is about the ability to use, when not possible otherwise, some good 
>>> > old feature such caller which is impossible to replicate when use strict 
>>> > is in place.
>>> >
>>> > I am talking about arguments.callee, I am talking about caller.
>>> 
>>> arguments.callee and .caller are not good features.
>>> 
>>> Being able to access your caller is a misfeature.
>>> 
>>> arguments.callee is simply unnecessary.
>>> 
>>> Also having the ability to lose strict semantics at arbitrary locations in 
>>> the middle of other strict modes makes things even slower, and adds all 
>>> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var 
>>> x;') do? -- this is hypothetical, just given as a trivial example of where 
>>> things go weird)
>>> 
>>> --Oliver
>>> 
>> 
>> 
> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

I believe with is much more problematic than caller for all Engines out
there. A reference to "who is invoking" cannot be that bad ... is it?
Anyway, even C and C++ can be compiled "insecurely" so my hope was that for
some extreme, well explained, documented, and needed code, the "no strict"
directve would have been allowed. Engines are easily switching already
between strict and no strict so I don't see, today, this problem at all,
included performance since as I have said, the web is running already "no
strict" thanks to minification.

br


On Thu, Nov 15, 2012 at 12:33 PM, Andreas Rossberg wrote:

> On 15 November 2012 21:20, Andrea Giammarchi
>  wrote:
> > thanks for your contribution to this thread, appreciated. I'd like a
> proper
> > answer now if that is possible.
>
> You already got rather strong answers from two members of TC39. It's
> safe to assume that the rest feels similar. To be clear: it's not only
> not planned, but it would happen only over the dead body of half of
> the committee. There were reasons why strict mode started ruling out
> 'caller' and 'with' in the first place.
>
> /Andreas
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andreas Rossberg]

On 15 November 2012 21:20, Andrea Giammarchi
 wrote:
> thanks for your contribution to this thread, appreciated. I'd like a proper
> answer now if that is possible.

You already got rather strong answers from two members of TC39. It's
safe to assume that the rest feels similar. To be clear: it's not only
not planned, but it would happen only over the dead body of half of
the committee. There were reasons why strict mode started ruling out
'caller' and 'with' in the first place.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

also, take a break if you have time and enjoy this talk:
http://www.youtube.com/watch?v=MFtijdklZDo


On Thu, Nov 15, 2012 at 12:32 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> funny, 'cause at least one use case I have implemented, is about improving
> performances at least 2X for 99% of OOP frameworks out there ... I guess
> you like function wrappers then to simulate caller when needed, right?
>
> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you
> don't mind and you are not already otherwise I'll stop here.
>
> br
>
>
> On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt  wrote:
>
>>
>> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> the debugger you mention is most likely using the with statement ...
>>
>>
>> No, the debugger is part of the virtual machine.  I'm aware that the
>> WebKit inspector currently has a rather annoying bug wrt executing code in
>> strict mode, but that's a _bug_.
>>
>>
>> Can we just stick with the answer if it is planned or not? I don't want
>> to convince you that there are cases where non strict features are needed
>> ... it is just like that and many times already discussed.
>>
>>
>> Not planned.
>>
>> Again, is there any real reason to not consider a "no strict" directive?
>> The whole web is running no strict thanks to minifiers so I really would
>> like to listen to real reasons over already discussed academic debates.
>>
>>
>> Because it would complicate the language, the implementation, and have
>> negative performance consequences.
>>
>> --Oliver
>>
>>
>>
>>
>> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
>>
>>>
>>> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> my typo ... I am NOT talking about callee, I am talking about caller
>>> which is NOT a misfeature specially when it comes to debug and stack trace.
>>>
>>>
>>> The solution to debugging is to use a debugger, not to try and debug
>>> from within the language.
>>>
>>> All modern JS engines provide a) a debugger and b) stack traces on
>>> exceptions.
>>>
>>> Even if they weren't .caller is insufficient: it can't walk over strict,
>>> native, or global code that exists in the call stack, so at best you only
>>> get a crappy result.
>>>
>>> Like I said in my prior email: If you're willing to toss out the
>>> improvements of strict mode just to get arguments.caller, you may as well
>>> stop using it in the first place.
>>>
>>> --Oliver
>>>
>>>
>>>
>>> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>>>

 On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
 andrea.giammar...@gmail.com> wrote:

 > I wonder if there is any plan to allow a chunk of code to disable for
 its own closure purpose a previously called "use strict"; directive.
 >
 > This is about the ability to use, when not possible otherwise, some
 good old feature such caller which is impossible to replicate when use
 strict is in place.
 >
 > I am talking about arguments.callee, I am talking about caller.

 arguments.callee and .caller are not good features.

 Being able to access your caller is a misfeature.

 arguments.callee is simply unnecessary.

 Also having the ability to lose strict semantics at arbitrary locations
 in the middle of other strict modes makes things even slower, and adds all
 sorts of weird semantic behaviours (eg. what would eval('"no strict"; var
 x;') do? -- this is hypothetical, just given as a trivial example of where
 things go weird)

 --Oliver

>>>
>>>
>>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

funny, 'cause at least one use case I have implemented, is about improving
performances at least 2X for 99% of OOP frameworks out there ... I guess
you like function wrappers then to simulate caller when needed, right?

Anyway, thanks ... I'd like to hear the same from some TC39 guy if you
don't mind and you are not already otherwise I'll stop here.

br


On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt  wrote:

>
> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> the debugger you mention is most likely using the with statement ...
>
>
> No, the debugger is part of the virtual machine.  I'm aware that the
> WebKit inspector currently has a rather annoying bug wrt executing code in
> strict mode, but that's a _bug_.
>
>
> Can we just stick with the answer if it is planned or not? I don't want to
> convince you that there are cases where non strict features are needed ...
> it is just like that and many times already discussed.
>
>
> Not planned.
>
> Again, is there any real reason to not consider a "no strict" directive?
> The whole web is running no strict thanks to minifiers so I really would
> like to listen to real reasons over already discussed academic debates.
>
>
> Because it would complicate the language, the implementation, and have
> negative performance consequences.
>
> --Oliver
>
>
>
>
> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
>
>>
>> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> my typo ... I am NOT talking about callee, I am talking about caller
>> which is NOT a misfeature specially when it comes to debug and stack trace.
>>
>>
>> The solution to debugging is to use a debugger, not to try and debug from
>> within the language.
>>
>> All modern JS engines provide a) a debugger and b) stack traces on
>> exceptions.
>>
>> Even if they weren't .caller is insufficient: it can't walk over strict,
>> native, or global code that exists in the call stack, so at best you only
>> get a crappy result.
>>
>> Like I said in my prior email: If you're willing to toss out the
>> improvements of strict mode just to get arguments.caller, you may as well
>> stop using it in the first place.
>>
>> --Oliver
>>
>>
>>
>> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>>
>>>
>>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> > I wonder if there is any plan to allow a chunk of code to disable for
>>> its own closure purpose a previously called "use strict"; directive.
>>> >
>>> > This is about the ability to use, when not possible otherwise, some
>>> good old feature such caller which is impossible to replicate when use
>>> strict is in place.
>>> >
>>> > I am talking about arguments.callee, I am talking about caller.
>>>
>>> arguments.callee and .caller are not good features.
>>>
>>> Being able to access your caller is a misfeature.
>>>
>>> arguments.callee is simply unnecessary.
>>>
>>> Also having the ability to lose strict semantics at arbitrary locations
>>> in the middle of other strict modes makes things even slower, and adds all
>>> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var
>>> x;') do? -- this is hypothetical, just given as a trivial example of where
>>> things go weird)
>>>
>>> --Oliver
>>>
>>
>>
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi  
wrote:

> the debugger you mention is most likely using the with statement ... 

No, the debugger is part of the virtual machine.  I'm aware that the WebKit 
inspector currently has a rather annoying bug wrt executing code in strict 
mode, but that's a _bug_.

> 
> Can we just stick with the answer if it is planned or not? I don't want to 
> convince you that there are cases where non strict features are needed ... it 
> is just like that and many times already discussed.

Not planned.

> Again, is there any real reason to not consider a "no strict" directive? The 
> whole web is running no strict thanks to minifiers so I really would like to 
> listen to real reasons over already discussed academic debates.

Because it would complicate the language, the implementation, and have negative 
performance consequences.

--Oliver

> 
> 
> 
> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:
> 
> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi  
> wrote:
> 
>> my typo ... I am NOT talking about callee, I am talking about caller which 
>> is NOT a misfeature specially when it comes to debug and stack trace.
> 
> The solution to debugging is to use a debugger, not to try and debug from 
> within the language.
> 
> All modern JS engines provide a) a debugger and b) stack traces on exceptions.
> 
> Even if they weren't .caller is insufficient: it can't walk over strict, 
> native, or global code that exists in the call stack, so at best you only get 
> a crappy result.
> 
> Like I said in my prior email: If you're willing to toss out the improvements 
> of strict mode just to get arguments.caller, you may as well stop using it in 
> the first place.
> 
> --Oliver
> 
>> 
>> 
>> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>> 
>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi 
>>  wrote:
>> 
>> > I wonder if there is any plan to allow a chunk of code to disable for its 
>> > own closure purpose a previously called "use strict"; directive.
>> >
>> > This is about the ability to use, when not possible otherwise, some good 
>> > old feature such caller which is impossible to replicate when use strict 
>> > is in place.
>> >
>> > I am talking about arguments.callee, I am talking about caller.
>> 
>> arguments.callee and .caller are not good features.
>> 
>> Being able to access your caller is a misfeature.
>> 
>> arguments.callee is simply unnecessary.
>> 
>> Also having the ability to lose strict semantics at arbitrary locations in 
>> the middle of other strict modes makes things even slower, and adds all 
>> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var 
>> x;') do? -- this is hypothetical, just given as a trivial example of where 
>> things go weird)
>> 
>> --Oliver
>> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

thanks for your contribution to this thread, appreciated. I'd like a proper
answer now if that is possible.


On Thu, Nov 15, 2012 at 12:18 PM, Andreas Rossberg wrote:

> On 15 November 2012 20:58, Andrea Giammarchi
>  wrote:
> > I am talking about caller which is NOT a misfeature
>
> Indeed, "misfeature" is putting it too mildly.
>
> /Andreas
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andreas Rossberg]

On 15 November 2012 20:58, Andrea Giammarchi
 wrote:
> I am talking about caller which is NOT a misfeature

Indeed, "misfeature" is putting it too mildly.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

the debugger you mention is most likely using the with statement ...

Can we just stick with the answer if it is planned or not? I don't want to
convince you that there are cases where non strict features are needed ...
it is just like that and many times already discussed.

The eval is a non issue, the script cannot be evaluated in any case ... an
eval('"use strict"') is a destructive non sense regardless and it should
simply throw an error. A Function('"use strict";') is another story.

I have never mentioned arguments, neither caller, which would be part of
arguments.callee and not arguments itself.

I can name function expressions, I always do, and the "no strict" is needed
for more than a case.

Again, is there any real reason to not consider a "no strict" directive?
The whole web is running no strict thanks to minifiers so I really would
like to listen to real reasons over already discussed academic debates.



On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt  wrote:

>
> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> my typo ... I am NOT talking about callee, I am talking about caller which
> is NOT a misfeature specially when it comes to debug and stack trace.
>
>
> The solution to debugging is to use a debugger, not to try and debug from
> within the language.
>
> All modern JS engines provide a) a debugger and b) stack traces on
> exceptions.
>
> Even if they weren't .caller is insufficient: it can't walk over strict,
> native, or global code that exists in the call stack, so at best you only
> get a crappy result.
>
> Like I said in my prior email: If you're willing to toss out the
> improvements of strict mode just to get arguments.caller, you may as well
> stop using it in the first place.
>
> --Oliver
>
>
>
> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>
>>
>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> > I wonder if there is any plan to allow a chunk of code to disable for
>> its own closure purpose a previously called "use strict"; directive.
>> >
>> > This is about the ability to use, when not possible otherwise, some
>> good old feature such caller which is impossible to replicate when use
>> strict is in place.
>> >
>> > I am talking about arguments.callee, I am talking about caller.
>>
>> arguments.callee and .caller are not good features.
>>
>> Being able to access your caller is a misfeature.
>>
>> arguments.callee is simply unnecessary.
>>
>> Also having the ability to lose strict semantics at arbitrary locations
>> in the middle of other strict modes makes things even slower, and adds all
>> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var
>> x;') do? -- this is hypothetical, just given as a trivial example of where
>> things go weird)
>>
>> --Oliver
>>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi  
wrote:

> my typo ... I am NOT talking about callee, I am talking about caller which is 
> NOT a misfeature specially when it comes to debug and stack trace.

The solution to debugging is to use a debugger, not to try and debug from 
within the language.

All modern JS engines provide a) a debugger and b) stack traces on exceptions.

Even if they weren't .caller is insufficient: it can't walk over strict, 
native, or global code that exists in the call stack, so at best you only get a 
crappy result.

Like I said in my prior email: If you're willing to toss out the improvements 
of strict mode just to get arguments.caller, you may as well stop using it in 
the first place.

--Oliver

> 
> 
> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
> 
> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi  
> wrote:
> 
> > I wonder if there is any plan to allow a chunk of code to disable for its 
> > own closure purpose a previously called "use strict"; directive.
> >
> > This is about the ability to use, when not possible otherwise, some good 
> > old feature such caller which is impossible to replicate when use strict is 
> > in place.
> >
> > I am talking about arguments.callee, I am talking about caller.
> 
> arguments.callee and .caller are not good features.
> 
> Being able to access your caller is a misfeature.
> 
> arguments.callee is simply unnecessary.
> 
> Also having the ability to lose strict semantics at arbitrary locations in 
> the middle of other strict modes makes things even slower, and adds all sorts 
> of weird semantic behaviours (eg. what would eval('"no strict"; var x;') do? 
> -- this is hypothetical, just given as a trivial example of where things go 
> weird)
> 
> --Oliver
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

On Nov 15, 2012, at 11:59 AM, Andrea Giammarchi  
wrote:

> gotcha about eval ... but indeed eval makes things slower in any case, right?

I wasn't commenting on the performance of eval, i was providing (and I stated 
this explicitly) a trivial case where the semantics immediately become weird.

wrt performance: Analysis to enforce strict mode restrictions is inherently 
more expensive than non-strict mode, but the moment you start allowing 
arbitrary entering an exiting of strict mode you are adding more cost, and for 
what reason?  

You have given two specific features, neither of which is good, and are willing 
to take every other misfeature of pre-strict JS in order to get them.  If you 
want misfeatures that aren't available in strict mode, and are willing to have 
your code be non-strict, why are you entering strict mode in the first place?

--Oliver

> 
> 
> On Thu, Nov 15, 2012 at 11:58 AM, Andrea Giammarchi 
>  wrote:
> my typo ... I am NOT talking about callee, I am talking about caller which is 
> NOT a misfeature specially when it comes to debug and stack trace.
> 
> 
> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
> 
> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi  
> wrote:
> 
> > I wonder if there is any plan to allow a chunk of code to disable for its 
> > own closure purpose a previously called "use strict"; directive.
> >
> > This is about the ability to use, when not possible otherwise, some good 
> > old feature such caller which is impossible to replicate when use strict is 
> > in place.
> >
> > I am talking about arguments.callee, I am talking about caller.
> 
> arguments.callee and .caller are not good features.
> 
> Being able to access your caller is a misfeature.
> 
> arguments.callee is simply unnecessary.
> 
> Also having the ability to lose strict semantics at arbitrary locations in 
> the middle of other strict modes makes things even slower, and adds all sorts 
> of weird semantic behaviours (eg. what would eval('"no strict"; var x;') do? 
> -- this is hypothetical, just given as a trivial example of where things go 
> weird)
> 
> --Oliver
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

gotcha about eval ... but indeed eval makes things slower in any case,
right?


On Thu, Nov 15, 2012 at 11:58 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> my typo ... I am NOT talking about callee, I am talking about caller which
> is NOT a misfeature specially when it comes to debug and stack trace.
>
>
> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:
>
>>
>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> > I wonder if there is any plan to allow a chunk of code to disable for
>> its own closure purpose a previously called "use strict"; directive.
>> >
>> > This is about the ability to use, when not possible otherwise, some
>> good old feature such caller which is impossible to replicate when use
>> strict is in place.
>> >
>> > I am talking about arguments.callee, I am talking about caller.
>>
>> arguments.callee and .caller are not good features.
>>
>> Being able to access your caller is a misfeature.
>>
>> arguments.callee is simply unnecessary.
>>
>> Also having the ability to lose strict semantics at arbitrary locations
>> in the middle of other strict modes makes things even slower, and adds all
>> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var
>> x;') do? -- this is hypothetical, just given as a trivial example of where
>> things go weird)
>>
>> --Oliver
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Andrea Giammarchi]

my typo ... I am NOT talking about callee, I am talking about caller which
is NOT a misfeature specially when it comes to debug and stack trace.


On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt  wrote:

>
> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> > I wonder if there is any plan to allow a chunk of code to disable for
> its own closure purpose a previously called "use strict"; directive.
> >
> > This is about the ability to use, when not possible otherwise, some good
> old feature such caller which is impossible to replicate when use strict is
> in place.
> >
> > I am talking about arguments.callee, I am talking about caller.
>
> arguments.callee and .caller are not good features.
>
> Being able to access your caller is a misfeature.
>
> arguments.callee is simply unnecessary.
>
> Also having the ability to lose strict semantics at arbitrary locations in
> the middle of other strict modes makes things even slower, and adds all
> sorts of weird semantic behaviours (eg. what would eval('"no strict"; var
> x;') do? -- this is hypothetical, just given as a trivial example of where
> things go weird)
>
> --Oliver
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "no strict"; directive

[Oliver Hunt]

On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi  
wrote:

> I wonder if there is any plan to allow a chunk of code to disable for its own 
> closure purpose a previously called "use strict"; directive.
> 
> This is about the ability to use, when not possible otherwise, some good old 
> feature such caller which is impossible to replicate when use strict is in 
> place.
> 
> I am talking about arguments.callee, I am talking about caller.

arguments.callee and .caller are not good features.

Being able to access your caller is a misfeature.

arguments.callee is simply unnecessary.

Also having the ability to lose strict semantics at arbitrary locations in the 
middle of other strict modes makes things even slower, and adds all sorts of 
weird semantic behaviours (eg. what would eval('"no strict"; var x;') do? -- 
this is hypothetical, just given as a trivial example of where things go weird)

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Allen Wirfs-Brock]

On Nov 15, 2012, at 11:33 AM, Kevin Smith wrote:

> I'm not quite sure how to figure this out from the current draft, but is 
> "let" only available from strict mode code?  This is valid under ES5 
> non-strict via ASI:

No, it is currently spec'ed as a reserved keyword in both regular and strict 
mode.

This is what TC39 agreed to try when we started down the 1JS path, with the 
expectation that implementation would explore the compatibility impact. 

If necessary, we should be able to make "let" a contextual keyword (only 
recognized as a statement head) followed by a [no LineTerminator here] in order 
to take care of the ASI case you show below.

> 
> var let = "123";
> let
>   x = "abc";
> 
> So with 1JS in mind, it would seem that "let" would only be a keyword in 
> strict mode.
> 
> Kevin
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

"no strict"; directive

[Andrea Giammarchi]

I wonder if there is any plan to allow a chunk of code to disable for its
own closure purpose a previously called "use strict"; directive.

This is about the ability to use, when not possible otherwise, some good
old feature such caller which is impossible to replicate when use strict is
in place.

I am talking about arguments.callee, I am talking about caller.

This could be useful to plug-in on demand the possibility to debug or
enhance possibilities through code considered harmful but actually
absolutely necessary in certain circumstances ( included the with statement
).

I know it's not new that someone wrote "don't use strict"; somewhere ...
but this is not funny anymore in certain projects that would like to be
included even in a script which logic is entirely under "use strict";
directive ( plug-ins etc )

Thanks
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

let and strict mode

[Kevin Smith]

I'm not quite sure how to figure this out from the current draft, but is
"let" only available from strict mode code?  This is valid under ES5
non-strict via ASI:

var let = "123";
let
  x = "abc";

So with 1JS in mind, it would seem that "let" would only be a keyword in
strict mode.

Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises

[Andreas Rossberg]

On 14 November 2012 20:37, Tom Van Cutsem  wrote:
> I still think futures connote strongly with blocking synchronization. If
> we'd add a concept named "future" to JS on the grounds that the same concept
> exists in Java and C++, developers will reasonably expect a blocking
> future.get() method.

I'd say that different notions of "concurrency" in respective
languages naturally affect the details of the future _interface_, but
I don't see this as a fundamental difference in the concept _as such_.
Somewhat like weak maps not having iteration, but still being maps.

The future interface in languages with threads is a superset of what
we can provide for JS. In those languages, you (can) have 'then' and
'wait'. Obviously, in a language without threads and only asynchronous
"concurrency", the latter operation is not available.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss