Consider the following code:
function f() { use strict; g() }
function g() {
var caller = Object.getOwnPropertyDescriptor(g, caller).value
}
With the current spec, this code would legally give g the strict
function f as its caller. In
Andreas Rossberg wrote:
On 12 November 2012 16:43, Mark S. Millererig...@google.com wrote:
The shift back to when clearly failed to achieve consensus.
FWIW, I think then is better, because when sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very
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.
Mmm... I think a [no LineTerm] restriction is going to bite too hard in
this case. If let in non-strict mode were a context-sensitive keyword,
with a
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
So the only code that would break would be expression statements
consisting of the single identifier let, followed by an ASI'd newline.
Is that right?
To reply to myself, there's also this:
var let = [], num = 0;
let[num] = f();
Hmmm
I suppose a radical but safe solution
Mark S. Miller wrote:
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote:
I think you meant optimally colored bikeshed, but OK.
Ouch : )
Names are important. Especially when it comes to something as
potentially confusing as
Andreas Rossberg wrote:
Consider the following code:
function f() { use strict; g() }
function g() {
var caller = Object.getOwnPropertyDescriptor(g, caller).value
}
With the current spec, this code would legally give g the strict
function f as its caller. In
Brandon Benvie wrote:
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
Brendan Eich wrote:
Nit: don't define a baseline and then mutate it. Better to have the
write immutable pd from the get-go, for each case.
Wow, jetlag: Better to have the right immutable pd, I meant.
/be
___
es-discuss mailing list
Whenever a function's name is defined by a Symbol instead of a regular
identifier then the name is the result of ToString(symbol).
Symbols don't have useful ToString conversions, do they? Are you thinking of
the optional string passed to the constructor, for diagnostics and debugging?
The
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
The language I used was a bit confusing with regards to the baseline and
what does what. In more direct, less spec-like language:
* Function.prototype.name is frozen and set to the empty string.
* named functions of any kind are also frozen and set to the name (how it
currently works in browsers
In regards to Symbols, yeah I was taking for granted them having a usable
value coming ToString that originates from the argument to the constructor.
I imagine that with syntactic support for Symbols this can mostly be
automated by lifting the ToString representation from the Symbol's
declaration.
Kevin Smith wrote:
var let = [], num = 0;
let[num] = f();
Awww, that's hard. I am really curious how this one is solved.
- Kevin
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Doesn't the same problem exist with:
var let = function() {};
let();
Or:
var let = { it: be };
let.it // be
On Fri, Nov 16, 2012 at 9:19 AM, Herby Vojčík he...@mailbox.sk wrote:
Kevin Smith wrote:
var let = [], num = 0;
let[num] = f();
Awww, that's hard. I
Yehuda Katz wrote:
Doesn't the same problem exist with:
var let = function() {};
let();
Or:
var let = { it: be };
let.it http://let.it // be
These seem to be parseable better (especially the latter), but how to
distiguish if
let [foo] = bar
is let with destructuring
var let = function() {};
let();
If let is a contextual keyword (in non-strict mode of course), then we can
look ahead to the token after `let` to validate it. An open paren cannot
follow a let *keyword*, so therefore it must be an identifier.
var let = { it: be };
let.it //
I implemented a JS parser last week (in JS) which specially parses the
function grammar. It also analyzes the function names based on the rules
you described, Brandon. I came to the same results when thinking about how
function names could be detected (statically).
But... there are some special
Hi Roger,
Thank you for the feedback! It's always good to hear from developers actually
using or planning to use the API we're putting together.
I saw Addison's and your follow-up, but will reply to this message because it
has the meat of your feedback. Note that my proposal has been approved
You might be interested in the work of Salman Mirghasemi on anonymous
function naming in JavaScript:
http://johnjbarton.github.com/nonymous/index.html
jjb
On Fri, Nov 16, 2012 at 11:34 AM, Aron Homberg i...@aron-homberg.de wrote:
I implemented a JS parser last week (in JS) which specially
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
Yeah, once you try to get fancy with interpolating a name you go down a
dark path real quick. I think that tends to be more in line with the
concept behind displayName which is the debug flavor of this and wants to
do heroic feats to trace a usable debug name. The name property should be
something
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
On 11/16/2012 07:06 AM, Brendan Eich wrote:
d8 function g() { Object.seal(g) }
d8 function f() { use strict; g() }
d8 f()
(d8):1: TypeError: Illegal access to a strict mode caller function.
(Interestingly, Firefox does not throw on that example, so I'm not
sure what semantics it actually
On 11/16/2012 01:19 PM, Jeff Walden wrote:
and to defer all the strictness checks to when the function provided as
|this| is actually invoked.
Er, that should be and to have the 'caller' [[Get]] function check the
strictness of the |this| function provided to it when that [[Get]] function is
@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
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
45 matches
Mail list logo
