On 16 November 2012 22:01, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
P.S. Alex, just to be as clear as possible, one answer I did not like that
much was that eval('no strict') nonsense ... that was not an answer 'cause
problems are the same with eval('use strict')
No, they are not.
it's about changing behavior inline, both cases should throw an error.
I won't try, I am just saying what I think should happen.
Said that, I am off this thread, I have clarified already everything I
needed to clarify and I am OK with everything anyone will say here.
Happy Monday everybody :-)
On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
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
I am still a big fun of what made JS easy to use, develop, learn since born
... the ability to include a script in a HTML page and run it without being
forced of using different tools in the middle before results or even
requiring a web server at all.
I remember once I've read that scripting was
On Thu, Nov 15, 2012 at 8:02 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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
AFAIK YUI Compressor does too
On Fri, Nov 16, 2012 at 12:21 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Nov 15, 2012 at 8:02 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
use strict is removed from code by default ... this is where it goes
once minified: nowhere.
I'm a huge fan of that too -- you know I don't like compilers as the answer
-- but that approach always comes with limits; and that's OK. What we add
to the spec lives forever; not just through the transition. We owe it to
ourselves and our users to introduce the least crazy we can while still
neither does `with` so the day use strict will be the default 90% of tests
frameworks will nicely break as well.
There are tons of libraries still based on ES3 and those evil things.
I am the first one to use always latest, and use strict too, but there are
cases where those evil things cannot
P.S. Alex, just to be as clear as possible, one answer I did not like that
much was that eval('no strict') nonsense ... that was not an answer
'cause problems are the same with eval('use strict') and we, JS
developers, are not always noobs or dumb.
It happens, from time to time, that we know what
@Oliver, if you need to retrieve the caller in order to know if it's strict
or not, then everything I've read in this thread becomes kinda pointless :-(
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184
It looks like there's no gain at all using strict and
On 11/16/2012 01:42 PM, Andrea Giammarchi wrote:
@Oliver, if you need to retrieve the caller in order to know if it's strict
or not, then everything I've read in this thread becomes kinda pointless :-(
Not quite. You could imagine a system where you simply have to know if your
caller is
but I don't see caller being any better/worse than arguments and I believe
arguments will stick around forever in any case ... so will caller,
unless there's not some specific personal reason but the code just looks
basically the same: find the rabbit and ta-da
Yes, it would be silly to
On 11/16/2012 02:11 PM, Andrea Giammarchi wrote:
but I don't see caller being any better/worse than arguments and I believe
arguments will stick around forever in any case ... so will caller, unless
there's not some specific personal reason but the code just looks basically
the same: find
I didn't misunderstand the cost ... I have said it's actually indeed
pointless to say it costs something since the simple check, that isStrict()
is performed at the end, when the rest of the logic has been moved already.
Thanks for all other infos
On Fri, Nov 16, 2012 at 2:31 PM, Oliver Hunt
On Nov 16, 2012, at 2:11 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
but I don't see caller being any better/worse than arguments and I believe
arguments will stick around forever in any case ... so will caller, unless
there's not some specific personal reason but the code
what I am saying: arguments won't disappear in 5+ years, neither will
caller ... is my crystal ball correct?
On Fri, Nov 16, 2012 at 2:34 PM, Jeff Walden jwalden...@mit.edu wrote:
On 11/16/2012 02:11 PM, Andrea Giammarchi wrote:
but I don't see caller being any better/worse than arguments
so dropping retrieve*Something*FromVMCode which I believe is one reason
methods with arguments/caller access cannot be optimized runtime properly
is not a performance/use strict goal ? So now I am confused ... gonna dig
there too ...
On Fri, Nov 16, 2012 at 2:36 PM, Oliver Hunt oli...@apple.com
On 11/16/2012 02:37 PM, Andrea Giammarchi wrote:
what I am saying: arguments won't disappear in 5+ years, neither will caller
... is my crystal ball correct?
It's not necessary for these things to disappear completely for us to derive
value from these decisions. It's only necessary for good
back in the topic ... about evaluation: Function('return this')(); returns
the global object with or without use strict around. This is actually nice,
since this one was a security problem introduced when somebody decided that
`this` without an explicit context should have been undefined. Now it
How does Function('return this;') differ from (1,eval)('this') ? In both
cases, if Function/eval is the original one, it executes its arguments
non-strictly. This is unfortunate but all the alternatives were worse. SES
replaces both Function and eval with safe variants that (among other
things)
Mark, who said that's different ? Why SES solves this and evaluation in the
global scope does not consider the use strict directive?
This is good news if known, it's a won't fix then: might be useful
On Fri, Nov 16, 2012 at 3:25 PM, Mark S. Miller erig...@google.com wrote:
How does Function
I don't think you understand the semantics here -- the Function constructor is
defined as taking a string (ignoring the parameters for now) and returning a
function as though the function was defined in the global scope. No functions
change behaviour based on the strictness of their caller.
you hear Mark? drop that SES solution. Is good to evaluate in the same
scope and context with a directive disabled inline and please read specs! (
sorry I could not resist but Oliver you are fun, I am going to read specs
now :-) )
On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt oli...@apple.com
On Nov 16, 2012, at 3:38 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
you hear Mark? drop that SES solution. Is good to evaluate in the same scope
and context with a directive disabled inline and please read specs! ( sorry I
could not resist but Oliver you are fun, I am going
sure, but I believe Mark did before me and SES fixed this issue indeed. I
understand it's different behind the scene, I don't understand why use
strict , which aim is to make code more secure, better, faster, can be
easily deactivated like that. I am talking about 3rd parts libraries that
could
Sstrict mode isn't meant to make JS secure (it just isn't possible to do so in
a non-break-the-web way, that's why SES exists and isn't just folded into the
language).
Strict mode tries to remove as many foot guns as possible, and make as many
probable errors fail as early as possible in an
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
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
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
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
...@apple.com 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
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
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
On 15 November 2012 20:58, Andrea Giammarchi
andrea.giammar...@gmail.com 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
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 rossb...@google.comwrote:
On 15 November 2012 20:58, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am talking about caller
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
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
.
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
On 15 November 2012 21:20, Andrea Giammarchi
andrea.giammar...@gmail.com 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
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
, 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
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
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
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
On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi andrea.giammar...@gmail.com
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
On Nov 15, 2012, at 12:32 PM, Andrea Giammarchi andrea.giammar...@gmail.com
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
On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com 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
On Nov 15, 2012, at 1:15 PM, David Herman dher...@mozilla.com wrote:
On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com 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
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
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
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
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.
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
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
54 matches
Mail list logo
