Problems with strict-mode caller poisoning
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
https://bugs.ecmascript.org/show_bug.cgi?id=310, Allen proposes the
obvious fix, which is to special case [[GetOwnProperty]] instead of
[[Get]] for function objects in 15.3.5.4. In fact, that is what both
V8 and FF already implement.
However, we recently discovered an issue with that semantics. Namely,
it causes Object.is{Sealed,Frozen} and Object.{seal,freeze} to
spuriously throw when applied to the wrong function at the wrong time.
Consider:
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 implements.)
What can we do here? There does not seem to be a clean fix, only more
hacks on top of hacks. It is a bit of a bummer for our implementation
of Object.observe, which wants an isFrozen check on its callback.
Thoughts?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promises
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 natural when taking continuations. Just a bikeshedding, but when as well as then are too ... deep, or how to say it, used in too many different situations in the plain English. IOW, they will undoubtedtly read awkward for certain scenarios. I myself found good old Smalltalk ifTrue: and ifFalse: fairly readable. Wouldn't it make sense to call them ifYes/ifOk/ifRight vs. ifNo/IfFailed/ifWrong? /Andreas Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let and strict mode
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 restriction that limits the lookahead to first tokens in binding
patterns, what kind of code would break?
some arbitrary statement or nothing let
(ident | { | [) some sequence of tokens
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?
If there's any working code out there like that, then it deserves to break
: )
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 use strict so I don't get this Closure Compiler choice. I don't see minified code with use strict that often All this suggests is that we need to improve the state of play in tools. Sounds doable. That said, you've gotten good answers that you don't like. It happens, and it's better than not getting an answer or getting a bad one. The polyfill you're working on can be accomplished other ways (http://code.google.com/p/traceur-compiler/). There's always a tax for emulating the new thing with the old, and this case that's caller. More to the point, it's a polyfill; once ES6 lands in engines, class syntax will give you super() for free, complete with whatever optimizations make sense. If you have performance issues, I recommend what everyone else here has: write benchmarks and file bugs. Beyond that, I think this horse is both dead and beaten. On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com 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 -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let and strict mode
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 would be to only allow let in strict mode. A carrot (or stick, depending on your point of view) to get users into strict? - Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises
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 promises and futures. I agree that names are important. 1) First choice would be to use existing words, where their existing meanings (whether nat-lang or prior technical use) clearly suggests their intended technical meaning. 2) Second choice would be to use words whose existing meanings do not conflict with their intended technical meaning, and where programmers do not mistakenly assume they know the wrong meaning. 3) Like #2, but coining new words if needed. 4...) anything else is too likely to cause confusion. When I see hardships around existing proposal, I go for something crazy. So #4 prbably according to above terminology. I would use .notyet (or .notYet) instead of .future for the end. Promise for the beginning seems fine (at least, there is only one of the promise/future pair), but I can as well see Will or Shall there. let foo = Will(...); let bar = foo.notyet; and later some matching API, like foo.done(...)/foo.wont(...) Herby In doing the E non-blocking promises, I looked at the history of usage of the terms promise and future. Several people had tried to use both terms in order to make a distinction. But historically, I could not find any consistency. For every interesting distinction, promise and future were used by someone on each side of the distinction. However, both were used primarily for the abstraction of designating a yet-to-be-determined value. Historically, the primary examples I can think of[1] of an abstraction that bundles both the delayed designation and the ability to determine what is designated is the logic variable (especially in concurrent logic languages) and the Python Deferred, which inspired various JS Defferds. If you consider this prior history of Deferreds to be significant, then our choices of Promise/Resolver/Deferred would be following strategy #1. Otherwise, Deferred is a new coinage and fits in strategy #3. Either way, Scala's unfortunate choice clearly violates this history in a confusing manner, so I'd classify it as #4. Let's not repeat Scala's mistake. [1] Off the top of my head now, without actually going back to the history. - Kevin -- Cheers, --MarkM ___ 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: Problems with strict-mode caller poisoning
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
https://bugs.ecmascript.org/show_bug.cgi?id=310, Allen proposes the
obvious fix, which is to special case [[GetOwnProperty]] instead of
[[Get]] for function objects in 15.3.5.4. In fact, that is what both
V8 and FF already implement.
SpiderMonkey in FF does this but not by layering on top of an exact
implementation equivalent of GetOwnProperty. Still, it's close enough
(more below).
However, we recently discovered an issue with that semantics. Namely,
it causes Object.is{Sealed,Frozen} and Object.{seal,freeze} to
spuriously throw when applied to the wrong function at the wrong time.
Consider:
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 implements.)
It looks like SpiderMonkey's Object.{seal,freeze,isSealed,isFrozen}
implementations do not call [[GetOwnProperty]] on each property. Cc'ing
Jeff Walden.
ES6 is redoing the spec internal methods and helpers, so layering
exactly as ES5 did is probably a mistake.
What can we do here? There does not seem to be a clean fix, only more
hacks on top of hacks. It is a bit of a bummer for our implementation
of Object.observe, which wants an isFrozen check on its callback.
Thoughts?
One thought: the spec (ES5 at least, not sure where ES6 drafts are on
redoing internal methods) customized [[Get]] for function objects to
avoid the value of caller leaking out. Reflecting on the property
descriptor for caller of a strict-mode function is ok so long as one
doesn't look at .value.
So it seems to me premature to throw on [[GetOwnProperty]] of a strict
function's 'caller'. It would be more precise, and avoid the problem
you're hitting, to return a property descriptor with a censored .value,
or a poisoned-pill throwing-accessor .value.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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 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.
The third goal needs more discussion. The displayName property consulted
by certain devtools (WebKit JS profiler, IIRC; others by now) was added
to avoid non-writable .name. With downrev browsers in the field, how can
we make name writable and let it be used cross-browser that way?
Semantics:
The baseline for every function is the 'name' property defined as
{ value: ,
writable: true,
enumerable: false,
configurable: false }.
SpiderMonkey's .name property of functions is like this except for
writable: false.
For FunctionDeclarations, named FunctionExpressions,
MethodDefinitions, or accessor Properties then the function's name
property is set to the given identifier.
Nit: don't define a baseline and then mutate it. Better to have the
write immutable pd from the get-go, for each case.
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.
at the front, to be super-clear ;-).
The name property is set to non-writable. Function.prototype's name
is also non-writable.
Oh, I see now: you made .name writable only as a spec-internal thing.
But wait, what about your goal 3?
Anonymous FunctionExpressions and ArrowFunctionExpressions assigned in
a VariableDeclaration or ObjectExpression
defined in an ObjectLiteral, rather.
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.
Really great stuff here, this makes me want to back your proposal. Just
need to hash out the nits and points of confusion (possibly mine).
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 name property should (probably) not have any reflection on the
output of Function.prototype.toString.
You mean if f.name is writable then f.toString() should not reflect
updates to f.name? Agreed, but why is f.name writable?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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 name would be more useful if it could be either string or symbol. Not sure about security implications, though. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 cool 'cause no time wasted compiling ... those days are gone in modern JS development. br On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.org wrote: 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 use strict so I don't get this Closure Compiler choice. I don't see minified code with use strict that often All this suggests is that we need to improve the state of play in tools. Sounds doable. That said, you've gotten good answers that you don't like. It happens, and it's better than not getting an answer or getting a bad one. The polyfill you're working on can be accomplished other ways ( http://code.google.com/p/traceur-compiler/). There's always a tax for emulating the new thing with the old, and this case that's caller. More to the point, it's a polyfill; once ES6 lands in engines, class syntax will give you super() for free, complete with whatever optimizations make sense. If you have performance issues, I recommend what everyone else here has: write benchmarks and file bugs. Beyond that, I think this horse is both dead and beaten. On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com 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 -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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 that support name)
* class constructors maintain how they would work when desugared to a
function, so represent the class for naming
* In unnamed functions (arrow + anonymous), if there is a statically
defined name that is appropriate to use then it is set as the name, but
remains writable since the code author never explicitly set the name.
Another place where a name could be used is in assignment to member
expressions where the property name is an identifier.
The following is all the places that should be covered and result in
writable named functions:
var declFunc = function(){}
var declArrow = () = {}
var declClass = class {}
var obj = {
propFunc: function(){},
popArrow: () = {},
propClass: class {}
}
object.memberFunc = function(){}
object.memberArrow = () = {}
object.memberClass = class {}
On Fri, Nov 16, 2012 at 10:31 AM, Brendan Eich bren...@mozilla.org wrote:
Brandon Benvie wrote:
This is based on http://wiki.ecmascript.org/**doku.php?id=strawman:name_*
*property_of_functionshttp://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.
The third goal needs more discussion. The displayName property consulted
by certain devtools (WebKit JS profiler, IIRC; others by now) was added to
avoid non-writable .name. With downrev browsers in the field, how can we
make name writable and let it be used cross-browser that way?
Semantics:
The baseline for every function is the 'name' property defined as
{ value: ,
writable: true,
enumerable: false,
configurable: false }.
SpiderMonkey's .name property of functions is like this except for
writable: false.
For FunctionDeclarations, named FunctionExpressions, MethodDefinitions,
or accessor Properties then the function's name property is set to the
given identifier.
Nit: don't define a baseline and then mutate it. Better to have the write
immutable pd from the get-go, for each case.
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.
at the front, to be super-clear ;-).
The name property is set to non-writable. Function.prototype's name is
also non-writable.
Oh, I see now: you made .name writable only as a spec-internal thing. But
wait, what about your goal 3?
Anonymous FunctionExpressions and ArrowFunctionExpressions assigned in a
VariableDeclaration or ObjectExpression
defined in an ObjectLiteral, rather.
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.
Really great stuff here, this makes me want to back your proposal. Just
need to hash out the nits and points of confusion (possibly mine).
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 name property should (probably) not have any reflection on the output
of Function.prototype.toString.
You mean if f.name is writable then f.toString() should not reflect
updates to f.name? Agreed, but why is f.name writable?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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.
On Fri, Nov 16, 2012 at 12:01 PM, Brandon Benvie
bran...@brandonbenvie.comwrote:
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 that support name)
* class constructors maintain how they would work when desugared to a
function, so represent the class for naming
* In unnamed functions (arrow + anonymous), if there is a statically
defined name that is appropriate to use then it is set as the name, but
remains writable since the code author never explicitly set the name.
Another place where a name could be used is in assignment to member
expressions where the property name is an identifier.
The following is all the places that should be covered and result in
writable named functions:
var declFunc = function(){}
var declArrow = () = {}
var declClass = class {}
var obj = {
propFunc: function(){},
popArrow: () = {},
propClass: class {}
}
object.memberFunc = function(){}
object.memberArrow = () = {}
object.memberClass = class {}
On Fri, Nov 16, 2012 at 10:31 AM, Brendan Eich bren...@mozilla.orgwrote:
Brandon Benvie wrote:
This is based on http://wiki.ecmascript.org/**doku.php?id=strawman:name_
**property_of_functionshttp://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.
The third goal needs more discussion. The displayName property consulted
by certain devtools (WebKit JS profiler, IIRC; others by now) was added to
avoid non-writable .name. With downrev browsers in the field, how can we
make name writable and let it be used cross-browser that way?
Semantics:
The baseline for every function is the 'name' property defined as
{ value: ,
writable: true,
enumerable: false,
configurable: false }.
SpiderMonkey's .name property of functions is like this except for
writable: false.
For FunctionDeclarations, named FunctionExpressions, MethodDefinitions,
or accessor Properties then the function's name property is set to the
given identifier.
Nit: don't define a baseline and then mutate it. Better to have the write
immutable pd from the get-go, for each case.
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.
at the front, to be super-clear ;-).
The name property is set to non-writable. Function.prototype's name is
also non-writable.
Oh, I see now: you made .name writable only as a spec-internal thing. But
wait, what about your goal 3?
Anonymous FunctionExpressions and ArrowFunctionExpressions assigned in a
VariableDeclaration or ObjectExpression
defined in an ObjectLiteral, rather.
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.
Really great stuff here, this makes me want to back your proposal. Just
need to hash out the nits and points of confusion (possibly mine).
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 name property should (probably) not have any reflection on the
output of Function.prototype.toString.
You mean if f.name is writable then f.toString() should not reflect
updates to f.name? Agreed, but why is f.name writable?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let and strict mode
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
Re: let and strict mode
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 am really curious how this one is solved.
- Kevin
Herby
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let and strict mode
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 or assignment with index?
On Fri, Nov 16, 2012 at 9:19 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
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
--
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let and strict mode
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 // be
Same logic applies. A dot cannot follow a let keyword so we parse it as an
identifier.
On the other hand, an open square bracket *can* follow a let keyword (by
array destructuring), so we have a potential ambiguity there.
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
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 cases where I wasn't able to find a good way
to detect a function's name properly. In one case, thats because my parser
just does a simple static parsing. Due to this, symbols are not evaluated
by toString(), like mentioned. But that's not the end of the story, there
are more pitfalls in practice...
A) Anonymous FunctionExpression's, stored in an array:
var someArray = [function() {
// Have
}, function() {
// a
}, function() {
// lot of
}, function() {
// fun
}];
e.g. Sencha's Ext JS does this in their Ext.data.Connection class where
it's used to determine which ActiveXObject instance to choose for an
XMLHttpRequest impl. in IE (calls the function in a loop)
I thought about combine sombol-name with array index, to give them a name.
It would look like: someArray-0, someArray-1, etc. but somehow I don't
really like that. Currently they are 'called': anonymous- + sequence++ -
I increase this sequence with each anonymous function detected to give
these functions a unique name (in script context).
B) FunctionExpression's assigned to a symbol:
var foo = {
barFn: null
};
foo[barFn] = function() {
// whatever
};
I faced this kind of code when parsing jQuery 1.8.1. It's hard to find a
smart way here. The property name could be a function call too or whatever.
So the name of the function is detected as symbol-assigned-anonymous- +
sequence++ here. For sure, function name could be foo[barFn] too. Maybe,
thats better for a developer in practice. With static analysis, these both
solutions are all I can do here. But dynamic evaluation of the symbol and
casting to a String, is too much for my static parsing algorithm.
Imagine stranger situations:
foo[fetchPropertyName()] = [function() {
// no
}, function() {
// fun
}];
Here a static function name detection fails too. A dynamic symbol to String
conversion can be dangerous in such a situation too, right?
C) Scoped functions:
(function() {
// what's my name?
})
No chance, this one is totally anonymous, right? No matter if static or
dynamic code analysis/parsing.
-
Now in practice: (parsing jQuery 1.8.1)
When I parse jQuery 1.8.1 using my parser, 511 functions get parsed and
their names get detected correctly. 137 functions apply to one of the three
special cases above. Most of them are symbol-assigned. Few are scoped by
(). One additional function is being instantiated using new
Function('$code'). I didn't implemented a name detection for this grammar
yet, so 138 of 511 functions are somehow anonymous after detecting
function names using my static parsing algorithm.
I wonder what your thoughts are regarding these special cases and my
decision to fallback to symbol-assigned-anonymous- + sequence++. Would
you prefer using the sourcecode of the symbol assignment as detected
function name name? It would be more descriptive in practice, right?
@Alex: The name would be more useful if it could be either string or
symbol
Please help me out :) The function will be assigned to the symbol, right?
So using the symbol as name would simply be a reference to the function
itself and equals to arguments.callee? Or did you mean the sourcecode of
the symbol as the detected name of the function like I mentioned above?
Thanks and regards,
- Aron
2012/11/16 Axel Rauschmayer a...@rauschma.de
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 name would be more useful if it could be either string or symbol. Not
sure about security implications, though.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
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: easy handling of UTF16 surrogates well-formed strings
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 by TC 39
for ES6, but Allen sometimes has to tweak details to match the rest of the
spec, and not all parts of the proposal are incorporated into the spec yet.
More inline below.
Regards,
Norbert
On Nov 14, 2012, at 6:06 , Roger Andrews wrote:
This is rather long but the idea is to make handling UTF16 surrogates
easier for the casual user without harming the ability of UTF16 experts to
delve into details if surrogates are not well-paired (and hence the string
is not well-formed).
Under the current definitions (ed. 6_10-26-12) surprising things happen.
E.g. a string converted to an array of codepoints with 'codePointAt' then
back to a string with 'fromCodePoint' is not equal to the original string
if it contains well-formed surrogate pairs.
Can you give an example usage scenario where this round-trip conversion is
necessary?
Note that my proposal contains an iterator [1] as a more convenient interface
for developers who need to access the code points of a string in sequence (this
hasn't made it into the spec yet). The current version returns substrings; an
alternative version could return integers - feedback on that would be helpful.
[1]
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html#String
Here are some thoughts from a JavaScript enthusiast playing with Unicode
outside the BMP.
String.prototype.codePointAt
The current definition of codePointAt has results:
out-of-bounds - Undefined
normal BMP char- the codepoint
lead surrogate of a good pair - the codepoint
trail surrogate of a good pair - codeunit in [0xDC00:0xDFFF] !!ambiguous
bad trail surrogate- codeunit in [0xDC00:0xDFFF]
bad lead surrogate - codeunit in [0xD800:0xDBFF]
Note that a well-paired trail surrogate still results in a value even though
the previous codeunit subsumed it. So, if a caller is indexing down the
string then it should take the well-paired trail surrogate value out of the
sequence.
UTF16 experts can write code to check these possibilities; but for general
usability lets have:
Undefined for the trail surrogate of a good pair, and
NaN for bad surrogate.
The current spec requires developers to check whether a returned code point is
above 0x and skip one string element if that's the case (see the
implementation of the proposed iterator). Your proposed spec requires them to
check whether a code point is *undefined* and skip it if that's the case. Is
that really better?
NaN seems a bad choice because it's not a code point and so forces callers to
check for it separately. For cases where the actual bad surrogate is not
wanted, U+FFFD is the standard choice.
Then codePointAt would do the work for the casual user and experts can probe
the string with charCodeAt (or codeUnitAt if it exists) if they really want
to know the situation of bad surrogates.
[Unchanged, users are called upon to write code patterns like the messy
// if the indexed position is part of a well-formed surrogate pair
// then result is either the entire code-point (for lead surrogates)
//or undefined (for trail surrogates)
// result is NaN for bad surrogates
// (result is always undefined for out-of-bounds position)
cp = str.codePointAt( pos );
if (0xDC00 = cpcp = 0xDFFF) {
cu = str.charCodeAt( pos-1 );
if (0xD800 = cucu = 0xDBFF) {
cp = undefined; // trail surrogate of good pair
}
}
if (0xD800 = cpcp = 0xDFFF) {
cp = NaN; // bad surrogate
}
]
That might be necessary if they really want to deal with undefined and NaN. I
think it would be more useful to look at actual usage scenarios and see how
they can be addressed using the iterator or codePointAt directly. Can you
provide some of the algorithms (simplified if necessary) where you're trying to
support supplementary characters?
String.prototype.charCodeAt / String.prototype.codeUnitAt
---
The existing charCodeAt returns NaN (not Undefined) if the indexed position
is out-of-bounds, unlike codePointAt.
For consistency, there could be a method 'codeUnitAt' which behaves like
(and is named like) codePointAt; i.e. returns Undefined for out-of-bounds.
There's been an argument that codePointAt should return NaN like codeUnitAt [2,
3; thread 4 for context]. What's your view on this?
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-August/024587.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-August/024606.html
[4]
Re: A new function name property proposal
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 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 cases where I wasn't able to find a good way
to detect a function's name properly. In one case, thats because my parser
just does a simple static parsing. Due to this, symbols are not evaluated
by toString(), like mentioned. But that's not the end of the story, there
are more pitfalls in practice...
A) Anonymous FunctionExpression's, stored in an array:
var someArray = [function() {
// Have
}, function() {
// a
}, function() {
// lot of
}, function() {
// fun
}];
e.g. Sencha's Ext JS does this in their Ext.data.Connection class where
it's used to determine which ActiveXObject instance to choose for an
XMLHttpRequest impl. in IE (calls the function in a loop)
I thought about combine sombol-name with array index, to give them a name.
It would look like: someArray-0, someArray-1, etc. but somehow I don't
really like that. Currently they are 'called': anonymous- + sequence++ -
I increase this sequence with each anonymous function detected to give
these functions a unique name (in script context).
B) FunctionExpression's assigned to a symbol:
var foo = {
barFn: null
};
foo[barFn] = function() {
// whatever
};
I faced this kind of code when parsing jQuery 1.8.1. It's hard to find a
smart way here. The property name could be a function call too or whatever.
So the name of the function is detected as symbol-assigned-anonymous- +
sequence++ here. For sure, function name could be foo[barFn] too. Maybe,
thats better for a developer in practice. With static analysis, these both
solutions are all I can do here. But dynamic evaluation of the symbol and
casting to a String, is too much for my static parsing algorithm.
Imagine stranger situations:
foo[fetchPropertyName()] = [function() {
// no
}, function() {
// fun
}];
Here a static function name detection fails too. A dynamic symbol to
String conversion can be dangerous in such a situation too, right?
C) Scoped functions:
(function() {
// what's my name?
})
No chance, this one is totally anonymous, right? No matter if static or
dynamic code analysis/parsing.
-
Now in practice: (parsing jQuery 1.8.1)
When I parse jQuery 1.8.1 using my parser, 511 functions get parsed and
their names get detected correctly. 137 functions apply to one of the three
special cases above. Most of them are symbol-assigned. Few are scoped by
(). One additional function is being instantiated using new
Function('$code'). I didn't implemented a name detection for this grammar
yet, so 138 of 511 functions are somehow anonymous after detecting
function names using my static parsing algorithm.
I wonder what your thoughts are regarding these special cases and my
decision to fallback to symbol-assigned-anonymous- + sequence++. Would
you prefer using the sourcecode of the symbol assignment as detected
function name name? It would be more descriptive in practice, right?
@Alex: The name would be more useful if it could be either string or
symbol
Please help me out :) The function will be assigned to the symbol, right?
So using the symbol as name would simply be a reference to the function
itself and equals to arguments.callee? Or did you mean the sourcecode of
the symbol as the detected name of the function like I mentioned above?
Thanks and regards,
- Aron
2012/11/16 Axel Rauschmayer a...@rauschma.de
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 name would be more useful if it could be either string or symbol. Not
sure about security implications, though.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
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
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 not use strict so I don't get this Closure Compiler choice. Is it just Closure Compiler or are there others you know of? Uglify.js doesn't remove use strict. Rick I don't see minified code with use strict that often On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 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. Is it just Closure Compiler or are there others you know of? Uglify.js doesn't remove use strict. Rick I don't see minified code with use strict that often On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.comwrote: 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 solving the most pressing problems; and to do it with an eye toward living in the future were specing. Caller doesn't pass this smell test. On Nov 16, 2012 4:55 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 cool 'cause no time wasted compiling ... those days are gone in modern JS development. br On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.orgwrote: 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 use strict so I don't get this Closure Compiler choice. I don't see minified code with use strict that often All this suggests is that we need to improve the state of play in tools. Sounds doable. That said, you've gotten good answers that you don't like. It happens, and it's better than not getting an answer or getting a bad one. The polyfill you're working on can be accomplished other ways ( http://code.google.com/p/traceur-compiler/). There's always a tax for emulating the new thing with the old, and this case that's caller. More to the point, it's a polyfill; once ES6 lands in engines, class syntax will give you super() for free, complete with whatever optimizations make sense. If you have performance issues, I recommend what everyone else here has: write benchmarks and file bugs. Beyond that, I think this horse is both dead and beaten. On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com 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 -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ 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: A new function name property proposal
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 that you'd actually purposefully write out yourself, not a
derived object path. This is where the writability comes in. If the author
does fail to hit the mark and doesn't provide a usable name, they can at
least manually set it after the fact.
On Fri, Nov 16, 2012 at 2:43 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
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.dewrote:
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 cases where I wasn't able to find a good
way to detect a function's name properly. In one case, thats because my
parser just does a simple static parsing. Due to this, symbols are not
evaluated by toString(), like mentioned. But that's not the end of the
story, there are more pitfalls in practice...
A) Anonymous FunctionExpression's, stored in an array:
var someArray = [function() {
// Have
}, function() {
// a
}, function() {
// lot of
}, function() {
// fun
}];
e.g. Sencha's Ext JS does this in their Ext.data.Connection class where
it's used to determine which ActiveXObject instance to choose for an
XMLHttpRequest impl. in IE (calls the function in a loop)
I thought about combine sombol-name with array index, to give them a
name. It would look like: someArray-0, someArray-1, etc. but somehow I
don't really like that. Currently they are 'called': anonymous- +
sequence++ - I increase this sequence with each anonymous function detected
to give these functions a unique name (in script context).
B) FunctionExpression's assigned to a symbol:
var foo = {
barFn: null
};
foo[barFn] = function() {
// whatever
};
I faced this kind of code when parsing jQuery 1.8.1. It's hard to find a
smart way here. The property name could be a function call too or whatever.
So the name of the function is detected as symbol-assigned-anonymous- +
sequence++ here. For sure, function name could be foo[barFn] too. Maybe,
thats better for a developer in practice. With static analysis, these both
solutions are all I can do here. But dynamic evaluation of the symbol and
casting to a String, is too much for my static parsing algorithm.
Imagine stranger situations:
foo[fetchPropertyName()] = [function() {
// no
}, function() {
// fun
}];
Here a static function name detection fails too. A dynamic symbol to
String conversion can be dangerous in such a situation too, right?
C) Scoped functions:
(function() {
// what's my name?
})
No chance, this one is totally anonymous, right? No matter if static or
dynamic code analysis/parsing.
-
Now in practice: (parsing jQuery 1.8.1)
When I parse jQuery 1.8.1 using my parser, 511 functions get parsed and
their names get detected correctly. 137 functions apply to one of the three
special cases above. Most of them are symbol-assigned. Few are scoped by
(). One additional function is being instantiated using new
Function('$code'). I didn't implemented a name detection for this grammar
yet, so 138 of 511 functions are somehow anonymous after detecting
function names using my static parsing algorithm.
I wonder what your thoughts are regarding these special cases and my
decision to fallback to symbol-assigned-anonymous- + sequence++. Would
you prefer using the sourcecode of the symbol assignment as detected
function name name? It would be more descriptive in practice, right?
@Alex: The name would be more useful if it could be either string or
symbol
Please help me out :) The function will be assigned to the symbol, right?
So using the symbol as name would simply be a reference to the function
itself and equals to arguments.callee? Or did you mean the sourcecode of
the symbol as the detected name of the function like I mentioned above?
Thanks and regards,
- Aron
2012/11/16 Axel Rauschmayer a...@rauschma.de
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 name would be more useful if it could be either string or symbol.
Not sure about security implications, though.
--
Dr.
Re: no strict; directive
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 be replaced and maybe are useful and for good. As long as there is a no strict behavior supported by engines I am good in any case but it's a pity we cannot have that solution today .. is the only one that makes sense out there, the only that does not suffer all other problems plus does not impact performance of each methods when super call is something actually not that common or not always needed when inheritance is in place. I've solved this a while ago with a better approach, even better than the currently de-sugared TypeScript, but developers are lazy and this new solution would have made them happy in their laziness. Thank everyone in any case for all inputs and thoughts and facts, I guess I am done here. br On Fri, Nov 16, 2012 at 12:38 PM, Alex Russell a...@dojotoolkit.org wrote: 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 solving the most pressing problems; and to do it with an eye toward living in the future were specing. Caller doesn't pass this smell test. On Nov 16, 2012 4:55 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 cool 'cause no time wasted compiling ... those days are gone in modern JS development. br On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.orgwrote: 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 use strict so I don't get this Closure Compiler choice. I don't see minified code with use strict that often All this suggests is that we need to improve the state of play in tools. Sounds doable. That said, you've gotten good answers that you don't like. It happens, and it's better than not getting an answer or getting a bad one. The polyfill you're working on can be accomplished other ways ( http://code.google.com/p/traceur-compiler/). There's always a tax for emulating the new thing with the old, and this case that's caller. More to the point, it's a polyfill; once ES6 lands in engines, class syntax will give you super() for free, complete with whatever optimizations make sense. If you have performance issues, I recommend what everyone else here has: write benchmarks and file bugs. Beyond that, I think this horse is both dead and beaten. On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com 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 -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ 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
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 we are talking about and
why we need this or that thing.
It's nice when here we keep it easy and quite ... it's also rare, imho.
On Fri, Nov 16, 2012 at 12:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 be replaced and maybe are useful and
for good.
As long as there is a no strict behavior supported by engines I am good
in any case but it's a pity we cannot have that solution today .. is the
only one that makes sense out there, the only that does not suffer all
other problems plus does not impact performance of each methods when super
call is something actually not that common or not always needed when
inheritance is in place.
I've solved this a while ago with a better approach, even better than the
currently de-sugared TypeScript, but developers are lazy and this new
solution would have made them happy in their laziness.
Thank everyone in any case for all inputs and thoughts and facts, I guess
I am done here.
br
On Fri, Nov 16, 2012 at 12:38 PM, Alex Russell a...@dojotoolkit.orgwrote:
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 solving the most pressing problems; and to do it with an eye toward
living in the future were specing. Caller doesn't pass this smell test.
On Nov 16, 2012 4:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 cool 'cause no time wasted
compiling ... those days are gone in modern JS development.
br
On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.orgwrote:
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 use strict so I don't get
this
Closure Compiler choice.
I don't see minified code with use strict that often
All this suggests is that we need to improve the state of play in
tools. Sounds doable.
That said, you've gotten good answers that you don't like. It happens,
and it's better than not getting an answer or getting a bad one.
The polyfill you're working on can be accomplished other ways (
http://code.google.com/p/traceur-compiler/). There's always a tax for
emulating the new thing with the old, and this case that's caller. More to
the point, it's a polyfill; once ES6 lands in engines, class syntax will
give you super() for free, complete with whatever optimizations make sense.
If you have performance issues, I recommend what everyone else here
has: write benchmarks and file bugs. Beyond that, I think this horse is
both dead and beaten.
On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com
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
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
Re: Problems with strict-mode caller poisoning
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 implements.)
It looks like SpiderMonkey's Object.{seal,freeze,isSealed,isFrozen}
implementations do not call [[GetOwnProperty]] on each property. Cc'ing Jeff
Walden.
They do, sort of, but .caller doesn't fit into the [[GetOwnProperty]] system
well in SpiderMonkey because, on functions that are not themselves strict (or
bound), it's neither a data property nor an accessor property. That this
happens to not complain vociferously is nearly happenstance at best. (I
suspect it did at one time, actually, and I bet I know the bug that changed it,
but it doesn't really matter in the end.)
So it seems to me premature to throw on [[GetOwnProperty]] of a strict
function's 'caller'. It would be more precise, and avoid the problem you're
hitting, to return a property descriptor with a censored .value, or a
poisoned-pill throwing-accessor .value.
premature to throw on [[GetOwnProperty]](caller) on a function whose caller
is strict, I assume you meant. That seems right to me. Since caller is a
time-variant characteristic, it seems right for the property to be an accessor,
probably existing solely on Function.prototype, and to defer all the strictness
checks to when the function provided as |this| is actually invoked.
Such a property is no different from anything already in the language, so I
can't see how it would at all interfere with Object.observe semantics or
implementation.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Problems with strict-mode caller poisoning
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 called. Too many function referents in play in all this discussion. :-\ Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
@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 the goal here is
simply to get rid of these calls exec-interpreter
()-retrieve*something*FromVMCode(exec, thisObj);
am I wrong? Can I ask when and if it's planned to get rid of this
isStrictMode() method? This, as info, would be definitively valuable ( FF
and Chrome guys welcome to answer to this as well, thanks )
On Fri, Nov 16, 2012 at 1:01 PM, 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') and we, JS
developers, are not always noobs or dumb.
It happens, from time to time, that we know what we are talking about and
why we need this or that thing.
It's nice when here we keep it easy and quite ... it's also rare, imho.
On Fri, Nov 16, 2012 at 12:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 be replaced and maybe are useful
and for good.
As long as there is a no strict behavior supported by engines I am good
in any case but it's a pity we cannot have that solution today .. is the
only one that makes sense out there, the only that does not suffer all
other problems plus does not impact performance of each methods when super
call is something actually not that common or not always needed when
inheritance is in place.
I've solved this a while ago with a better approach, even better than the
currently de-sugared TypeScript, but developers are lazy and this new
solution would have made them happy in their laziness.
Thank everyone in any case for all inputs and thoughts and facts, I guess
I am done here.
br
On Fri, Nov 16, 2012 at 12:38 PM, Alex Russell a...@dojotoolkit.orgwrote:
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 solving the most pressing problems; and to do it with an eye toward
living in the future were specing. Caller doesn't pass this smell test.
On Nov 16, 2012 4:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 cool 'cause no time wasted
compiling ... those days are gone in modern JS development.
br
On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.orgwrote:
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 use strict so I don't get
this
Closure Compiler choice.
I don't see minified code with use strict that often
All this suggests is that we need to improve the state of play in
tools. Sounds doable.
That said, you've gotten good answers that you don't like. It happens,
and it's better than not getting an answer or getting a bad one.
The polyfill you're working on can be accomplished other ways (
http://code.google.com/p/traceur-compiler/). There's always a tax for
emulating the new thing with the old, and this case that's caller. More to
the point, it's a polyfill; once ES6 lands in engines, class syntax will
give you super() for free, complete with whatever optimizations make
sense.
If you have performance issues, I recommend what everyone else here
has: write benchmarks and file bugs. Beyond that, I think this horse is
both dead and beaten.
On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich bren...@mozilla.com
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
Re: no strict; directive
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 strict or not. If it is, then you don't need to track any of that info. If it isn't, then you'd need some system to compute the caller. But it's certainly not the case that you always have to keep the caller around regardless. https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184 It looks like there's no gain at all using strict and the goal here is simply to get rid of these calls exec-interpreter ()-retrieve*something*FromVMCode(exec, thisObj); Just to note, knowing that it's impossible to access the caller also benefits inlining -- you don't have to be able to recompute the caller function (or all the inlined function's stack modifications) at any moment when you're in function code that's been inlined in a caller. I would provide you a link to a blog post I wrote a year or so ago with more details on this, but it's currently down. :-( Maybe I should spend the time to bring it back up now so I can pass that link along. am I wrong? Can I ask when and if it's planned to get rid of this isStrictMode() method? This, as info, would be definitively valuable ( FF and Chrome guys welcome to answer to this as well, thanks ) I wouldn't speculate as to when any engine will take advantage of this -- SpiderMonkey that I work on, or any of the others. It's still somewhat early in the JS optimization race, so it's likely there's more low-hanging fruit to be picked in all the engines, that benefits all code and not just strict mode code, before this would happen. As regards SpiderMonkey particularly, I think we have enough things on our plates now that taking advantage of this particular optimization opportunity won't happen in the next year or so. Taking advantage of this also has some interesting interactions with other functionality like debuggers, Error.stack, error messages, and so on. The simple thing, that's been done forever, is to just always track it. But there's no reason not to specialize, and optimize harder, in the cases where these complications can be worked around or set aside. In the long run, however, something like this will happen. It would be short-sighted to take on the semantic nightmare mid-stream strict mode opt-out would present, simply because engines aren't immediately taking advantage of all the optimization opportunities strict mode presents. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 create today something based on an assumption such future browsers optimizations will come after ES6 but on the practical level we all know it's going to be like that, right? Or even ES7 ... thanks for your answer. On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden jwalden...@mit.edu wrote: 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 strict or not. If it is, then you don't need to track any of that info. If it isn't, then you'd need some system to compute the caller. But it's certainly not the case that you always have to keep the caller around regardless. https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184 It looks like there's no gain at all using strict and the goal here is simply to get rid of these calls exec-interpreter ()-retrieve*something*FromVMCode(exec, thisObj); Just to note, knowing that it's impossible to access the caller also benefits inlining -- you don't have to be able to recompute the caller function (or all the inlined function's stack modifications) at any moment when you're in function code that's been inlined in a caller. I would provide you a link to a blog post I wrote a year or so ago with more details on this, but it's currently down. :-( Maybe I should spend the time to bring it back up now so I can pass that link along. am I wrong? Can I ask when and if it's planned to get rid of this isStrictMode() method? This, as info, would be definitively valuable ( FF and Chrome guys welcome to answer to this as well, thanks ) I wouldn't speculate as to when any engine will take advantage of this -- SpiderMonkey that I work on, or any of the others. It's still somewhat early in the JS optimization race, so it's likely there's more low-hanging fruit to be picked in all the engines, that benefits all code and not just strict mode code, before this would happen. As regards SpiderMonkey particularly, I think we have enough things on our plates now that taking advantage of this particular optimization opportunity won't happen in the next year or so. Taking advantage of this also has some interesting interactions with other functionality like debuggers, Error.stack, error messages, and so on. The simple thing, that's been done forever, is to just always track it. But there's no reason not to specialize, and optimize harder, in the cases where these complications can be worked around or set aside. In the long run, however, something like this will happen. It would be short-sighted to take on the semantic nightmare mid-stream strict mode opt-out would present, simply because engines aren't immediately taking advantage of all the optimization opportunities strict mode presents. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 the rabbit and ta-da The arguments keyword is statically detectable (or can be hedged against in the much-worse possible use of eval), which makes it far better. fun.arguments and fun.caller are about equally bad. And to the extent there are correct semantics for fun.arguments, engines break those daily whenever optimization opportunities present themselves. In the longer run the code will not look basically the same, so arguing from what the code looks like now, in any engine, is not especially convincing. but on the practical level we all know it's going to be like that, right? I don't understand what you're saying/implying here. Could you spell it out more clearly, please? Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 oli...@apple.com wrote:
On Nov 16, 2012, at 1:42 PM, Andrea Giammarchi
andrea.giammar...@gmail.com 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 :-(
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184
It looks like there's no gain at all using strict and the goal here is
simply to get rid of these calls exec-interpreter
()-retrieve*something*FromVMCode(exec, thisObj);
am I wrong? Can I ask when and if it's planned to get rid of
this isStrictMode() method? This, as info, would be definitively valuable (
FF and Chrome guys welcome to answer to this as well, thanks )
Okay, so there are two issues:
1. calling someFunction.caller when someFunction is itself strict
2. calling someFunction.caller when someFunction.caller is strict
1. is trivial: before we do any work we check whether someFunction is
strict and throw if appropriate
2. is weird -- this code post-dates my original strict mode
implementation, presumably it exists due to someone adding a test for it in
test262.
I'm not sure of what the value of the restriction in (2) is meant to be,
I'm sure MarkM or Waldemar could say for sure, but I assume it's part of
the early failure desires of strict mode. My personal bias in favour of
code that continues to run all the time means I would rather return null
(after all null is already a possible result).
Okay, that aside you seem to be misunderstanding what the cost model is
here. Calling isStrictMode() is obviously trivial (there's a bool flag
that says whether a function is strict).
But that's not the cost we're concerned about. There's a lot of
complexity in the engine that is required in order to support .caller, and
a lot of runtime costs involved in storing the things that are necessary
for recovering it.
This is the algorithm that .caller has to use is basically:
GetCaller(function)
stackFrame = topStackFrame
while (stackFrame) {
callerFrame = stackFrame.callerFrame
if (stackFrame.callee == function) {
if (!callerFrame || !isFunction(callerFrame.callee))
return null
return callerFrame.callee
}
stackFrame = callerFrame
}
return null
So this is expensive on its own and prevents tailcall optimisations
(because a tailcall directly breaks .caller).
The other problems are that trying to retrieve callerFrame is not free, it
requires undoing inlining and a variety of other optimisations, recreating
a correct call stack (not cheap) and potentially disables those
optimisations again in the future.
Again the cost here is not checking for strict mode it's:
* The cost of walking the stack
* The cost of storing information required to determine what the actual
function object is so we can give you the caller function, rather than the
internal type that contains the function metadata (even if you never use
.caller)
* The cost of deoptimising code when .caller is actually used
* The opportunity cost of completely preventing certain classes of
optimisation (again: even if you never use .caller)
Strict mode disables .caller because it is a misfeature, however we're
still required to support it for non-strict code hence the very large
amounts of code needed for it continues to exist.
--Oliver
On Fri, Nov 16, 2012 at 1:01 PM, 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') and we, JS
developers, are not always noobs or dumb.
It happens, from time to time, that we know what we are talking about and
why we need this or that thing.
It's nice when here we keep it easy and quite ... it's also rare, imho.
On Fri, Nov 16, 2012 at 12:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 be replaced and maybe are useful and
for good.
As long as there is a no strict behavior supported by engines I am good
in any case but it's a pity we cannot have that solution today .. is the
only one that makes sense out there, the only that does not suffer all
other problems plus does not impact performance of each methods when super
call is
Re: no strict; directive
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 just looks basically the same: find the rabbit and ta-da Yes, it would be silly to create today something based on an assumption such future browsers optimizations will come after ES6 but on the practical level we all know it's going to be like that, right? Or even ES7 ... thanks for your answer. Not understanding how features need to be/are implemented (or an unwillingness to investigate) isn't a good basis for making statements like this. What you seem to be (willfully) ignoring is that someFunction.caller requires a stack walk. That is what it is defined as doing. |arguments| is a magic _local_ variable - there is no stack walk involved, only the local call frame matters, there is no stack reconstruction necessary (in the sane use cases any way - insane use cases trigger dramatic costs, and someFunction.arguments has all the problems on someFunction.caller, with a few additional costs thrown in for good measure). --Oliver On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden jwalden...@mit.edu wrote: 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 strict or not. If it is, then you don't need to track any of that info. If it isn't, then you'd need some system to compute the caller. But it's certainly not the case that you always have to keep the caller around regardless. https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184 It looks like there's no gain at all using strict and the goal here is simply to get rid of these calls exec-interpreter ()-retrieve*something*FromVMCode(exec, thisObj); Just to note, knowing that it's impossible to access the caller also benefits inlining -- you don't have to be able to recompute the caller function (or all the inlined function's stack modifications) at any moment when you're in function code that's been inlined in a caller. I would provide you a link to a blog post I wrote a year or so ago with more details on this, but it's currently down. :-( Maybe I should spend the time to bring it back up now so I can pass that link along. am I wrong? Can I ask when and if it's planned to get rid of this isStrictMode() method? This, as info, would be definitively valuable ( FF and Chrome guys welcome to answer to this as well, thanks ) I wouldn't speculate as to when any engine will take advantage of this -- SpiderMonkey that I work on, or any of the others. It's still somewhat early in the JS optimization race, so it's likely there's more low-hanging fruit to be picked in all the engines, that benefits all code and not just strict mode code, before this would happen. As regards SpiderMonkey particularly, I think we have enough things on our plates now that taking advantage of this particular optimization opportunity won't happen in the next year or so. Taking advantage of this also has some interesting interactions with other functionality like debuggers, Error.stack, error messages, and so on. The simple thing, that's been done forever, is to just always track it. But there's no reason not to specialize, and optimize harder, in the cases where these complications can be worked around or set aside. In the long run, however, something like this will happen. It would be short-sighted to take on the semantic nightmare mid-stream strict mode opt-out would present, simply because engines aren't immediately taking advantage of all the optimization opportunities strict mode presents. Jeff ___ 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
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 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 The arguments keyword is statically detectable (or can be hedged against in the much-worse possible use of eval), which makes it far better. fun.arguments and fun.caller are about equally bad. And to the extent there are correct semantics for fun.arguments, engines break those daily whenever optimization opportunities present themselves. In the longer run the code will not look basically the same, so arguing from what the code looks like now, in any engine, is not especially convincing. but on the practical level we all know it's going to be like that, right? I don't understand what you're saying/implying here. Could you spell it out more clearly, please? Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 wrote: 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 just looks basically the same: find the rabbit and ta-da Yes, it would be silly to create today something based on an assumption such future browsers optimizations will come after ES6 but on the practical level we all know it's going to be like that, right? Or even ES7 ... thanks for your answer. Not understanding how features need to be/are implemented (or an unwillingness to investigate) isn't a good basis for making statements like this. What you seem to be (willfully) ignoring is that someFunction.caller requires a stack walk. That is what it is defined as doing. |arguments| is a magic _local_ variable - there is no stack walk involved, only the local call frame matters, there is no stack reconstruction necessary (in the sane use cases any way - insane use cases trigger dramatic costs, and someFunction.arguments has all the problems on someFunction.caller, with a few additional costs thrown in for good measure). --Oliver On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden jwalden...@mit.edu wrote: 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 strict or not. If it is, then you don't need to track any of that info. If it isn't, then you'd need some system to compute the caller. But it's certainly not the case that you always have to keep the caller around regardless. https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184 It looks like there's no gain at all using strict and the goal here is simply to get rid of these calls exec-interpreter ()-retrieve*something*FromVMCode(exec, thisObj); Just to note, knowing that it's impossible to access the caller also benefits inlining -- you don't have to be able to recompute the caller function (or all the inlined function's stack modifications) at any moment when you're in function code that's been inlined in a caller. I would provide you a link to a blog post I wrote a year or so ago with more details on this, but it's currently down. :-( Maybe I should spend the time to bring it back up now so I can pass that link along. am I wrong? Can I ask when and if it's planned to get rid of this isStrictMode() method? This, as info, would be definitively valuable ( FF and Chrome guys welcome to answer to this as well, thanks ) I wouldn't speculate as to when any engine will take advantage of this -- SpiderMonkey that I work on, or any of the others. It's still somewhat early in the JS optimization race, so it's likely there's more low-hanging fruit to be picked in all the engines, that benefits all code and not just strict mode code, before this would happen. As regards SpiderMonkey particularly, I think we have enough things on our plates now that taking advantage of this particular optimization opportunity won't happen in the next year or so. Taking advantage of this also has some interesting interactions with other functionality like debuggers, Error.stack, error messages, and so on. The simple thing, that's been done forever, is to just always track it. But there's no reason not to specialize, and optimize harder, in the cases where these complications can be worked around or set aside. In the long run, however, something like this will happen. It would be short-sighted to take on the semantic nightmare mid-stream strict mode opt-out would present, simply because engines aren't immediately taking advantage of all the optimization opportunities strict mode presents. Jeff ___ 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
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 code, that wants to be performant, to not use them. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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) enforce that the argument is executed as strict code.
On Fri, Nov 16, 2012 at 3:19 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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('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) enforce that the argument is executed as strict code.
On Fri, Nov 16, 2012 at 3:19 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 is possible to retrieve the global object as long as
Function is the original constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: no strict; directive
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. The only way to make
a string execute as javascript inside the scope of another function is to use
the eval _operator_. These are fundamentally different concepts.
To put it another way, if the Function constructors behaviour was dependent on
the strictness of its caller, i would expect:
document.write(script/*code here*//+script);
to produce an script element that was already in strict mode.
You really need to read the spec, as you seem to be misunderstanding some very
fundamental concepts.
--Oliver
On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that wants to
be performant, to not use them.
Jeff
___
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
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 wrote:
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. The only way to make a string execute as javascript inside the
scope of another function is to use the eval _operator_. These are
fundamentally different concepts.
To put it another way, if the Function constructors behaviour was
dependent on the strictness of its caller, i would expect:
document.write(script/*code here*//+script);
to produce an script element that was already in strict mode.
You really need to read the spec, as you seem to be misunderstanding some
very fundamental concepts.
--Oliver
On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
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
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 to read specs now :-) )
I'm not sure where you got that from, if you felt I was being offensive I
apologise, but I'm serious, you need to read the spec; There are very real,
and very important semantic differences between using eval as an operator, and
calling any other function. Likewise there are very important behavioural
differences between accessing the arguments value inside a function body, and
accessing the caller property of a function object. There are major semantic
differences between the concepts of a function object, a function's environment
record, and the function code itself. To meaningfully discuss the behaviour
and semantics of these things (and their interactions with strict mode) you
need to understand all of these concepts and how they relate.
--Oliver
On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt oli...@apple.com wrote:
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. The only
way to make a string execute as javascript inside the scope of another
function is to use the eval _operator_. These are fundamentally different
concepts.
To put it another way, if the Function constructors behaviour was dependent
on the strictness of its caller, i would expect:
document.write(script/*code here*//+script);
to produce an script element that was already in strict mode.
You really need to read the spec, as you seem to be misunderstanding some
very fundamental concepts.
--Oliver
On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that wants
to be performant, to not use them.
Jeff
___
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
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 decide to run **non strict** inside whatever use strict environment
due that Function/(1,eval) door.
If this is not risky then I am missing what is this use strict about
since there were already linters to tell us what's good and what's not on
code level, I am sorry if I don't understand.
br
On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt oli...@apple.com wrote:
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 to read specs
now :-) )
I'm not sure where you got that from, if you felt I was being offensive I
apologise, but I'm serious, you need to read the spec; There are very
real, and very important semantic differences between using eval as an
operator, and calling any other function. Likewise there are very
important behavioural differences between accessing the arguments value
inside a function body, and accessing the caller property of a function
object. There are major semantic differences between the concepts of a
function object, a function's environment record, and the function code
itself. To meaningfully discuss the behaviour and semantics of these
things (and their interactions with strict mode) you need to understand all
of these concepts and how they relate.
--Oliver
On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt oli...@apple.com wrote:
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. The only way to make a string execute as javascript inside the
scope of another function is to use the eval _operator_. These are
fundamentally different concepts.
To put it another way, if the Function constructors behaviour was
dependent on the strictness of its caller, i would expect:
document.write(script/*code here*//+script);
to produce an script element that was already in strict mode.
You really need to read the spec, as you seem to be misunderstanding some
very fundamental concepts.
--Oliver
On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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 is possible to retrieve the global object as long as
Function is the original constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
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
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 attempt to rectify old bugs
from the early days of JS (accidental creation of globals, bizzaro behaviour
when assigning to arguments, etc). Killing off with() had significant security
benefits, but the bigger win is that with() has really crazy that makes it
impossible to reason about code in any meaningful way.
SES on the other hand sets things up so that you can include untrusted 3rd
party content in verifiably safe ways, something that strict mode does nothing
to address. Strict mode helps SES a lot by making it possible to have
essentially static control over all the otherwise unsafe things that can be
done normally.
--Oliver
On Nov 16, 2012, at 3:56 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
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 decide to run **non strict** inside whatever use strict environment
due that Function/(1,eval) door.
If this is not risky then I am missing what is this use strict about since
there were already linters to tell us what's good and what's not on code
level, I am sorry if I don't understand.
br
On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt oli...@apple.com wrote:
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 to read specs now :-) )
I'm not sure where you got that from, if you felt I was being offensive I
apologise, but I'm serious, you need to read the spec; There are very real,
and very important semantic differences between using eval as an operator,
and calling any other function. Likewise there are very important
behavioural differences between accessing the arguments value inside a
function body, and accessing the caller property of a function object. There
are major semantic differences between the concepts of a function object, a
function's environment record, and the function code itself. To meaningfully
discuss the behaviour and semantics of these things (and their interactions
with strict mode) you need to understand all of these concepts and how they
relate.
--Oliver
On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt oli...@apple.com wrote:
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. The
only way to make a string execute as javascript inside the scope of another
function is to use the eval _operator_. These are fundamentally different
concepts.
To put it another way, if the Function constructors behaviour was dependent
on the strictness of its caller, i would expect:
document.write(script/*code here*//+script);
to produce an script element that was already in strict mode.
You really need to read the spec, as you seem to be misunderstanding some
very fundamental concepts.
--Oliver
On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
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 is
possible to retrieve the global object as long as Function is the original
constructor.
Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
suffering)
Please do not fix, thanks :-)
On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
love this answer, thanks!
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden jwalden...@mit.edu wrote:
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 code, that
wants to be performant, to not use them.
Jeff
___
es-discuss mailing list
