Updating this thread. I need to update the wiki still, but at last
week's TC39 meeting we did agree to infer name mostly as you proposed.
The one change of note is to make f.name writable always.
BTW, I just noticed that SpiderMonkey infers a display id now, along
the lines of your proposal:
On 25/11/2012, at 00:52, Brendan Eich wrote:
No. You're rehashing a hypothetical worry at this point.
No worries, but it's not a hypothesis that code outside a recursive FD can
break it at its will.
Evidence first, to get any farther.
The only evidence is that sometimes yes sometimes no,
On 24/11/2012, at 07:14, Brendan Eich wrote:
Jorge Chamorro wrote:
Bind the name inside the function *too*.
That's not a compatible change, and unmotivated by any actual foot damage.
The footgun (1) is to have the name bound *only* in the outer scope.
We need evidence this is a real
Jorge Chamorro wrote:
On 24/11/2012, at 07:14, Brendan Eich wrote:
Programmers do intentionally replace a function's name in its scope, e.g. to
auto-memoize.
Oh, how does that work? I've written memoizers but never needed to overwrite a
name.
On 22/11/2012, at 09:38, Brendan Eich wrote:
Brandon Benvie wrote:
I don't know the specific reasoning behind it. I guess the idea is that a
function is declared in a maximum of one scope. For the declaration it's the
outer scope, for a named function expression it's a static scope that sits
In ES6 methods (both in classes and in object literals) don't create any
binding at all for their name. Would you say that's better or worse?
As far as changing the binding behavior of names for existing function
declaration and expression forms...it'd be fiddling with something that has
(I
Jorge Chamorro wrote:
On 22/11/2012, at 09:38, Brendan Eich wrote:
Brandon Benvie wrote:
I don't know the specific reasoning behind it. I guess the idea is that a
function is declared in a maximum of one scope. For the declaration it's the
outer scope, for a named function expression it's a
On 23/11/2012, at 18:47, Brendan Eich wrote:
Jorge Chamorro wrote:
On 22/11/2012, at 09:38, Brendan Eich wrote:
Right. I think Jorge may be concerned that naming a function does not
always relieve the need for arguments.callee. But that's only true in a
function declaration, which is
Jorge Chamorro wrote:
On 23/11/2012, at 18:47, Brendan Eich wrote:
Jorge Chamorro wrote:
On 22/11/2012, at 09:38, Brendan Eich wrote:
Right. I think Jorge may be concerned that naming a function does not always relieve the
need for arguments.callee. But that's only true in a function
Brandon Benvie wrote:
I don't know the specific reasoning behind it. I guess the idea is
that a function is declared in a maximum of one scope. For the
declaration it's the outer scope, for a named function expression it's
a static scope that sits between the outer scope and the (during
On 19/11/2012, at 20:34, Brandon Benvie wrote:
On Mon, Nov 19, 2012 at 2:29 PM, Jorge Chamorro Bieling
jo...@jorgechamorro.com wrote:
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't currently (and the I don't propose it should)
have a correlation to the name in
I don't know the specific reasoning behind it. I guess the idea is that a
function is declared in a maximum of one scope. For the declaration it's
the outer scope, for a named function expression it's a static scope that
sits between the outer scope and the (during execution of the function)
inner
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't currently (and the I don't propose it should) have
a correlation to the name in scope. In function declarations the name is only
in scope because its declared in the outer scope, and this can be overwritten
function x(){ x = { name: 'y' }; return x.name } x(); // 'y'
(function x(){ x = { name: 'y' }; return x.name })() // 'x'
On Mon, Nov 19, 2012 at 2:29 PM, Jorge Chamorro Bieling
jo...@jorgechamorro.com wrote:
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't
On 16/11/2012, at 21:46, Brandon Benvie wrote:
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
@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
The name property doesn't currently (and the I don't propose it should)
have a correlation to the name in scope. In function declarations the name
is only in scope because its declared in the outer scope, and this can be
overwritten permanently rendering the name unusable in that scope. A named
Declarative scope...not decorative scope. Curses auto correct fail.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brandon: thanks for reviving and revising my old strawman. I will edit
your proposed changes in (and let you and the list know when I'm done so
you can review) and present at the TC39 meeting in the last week of
November. Thanks again, great work!
/be
Brandon Benvie wrote:
Declarative
Excellent! I must admit to having a pretty ridiculous obsession with the
name property of functions in particular, so I would be much delighted to
see improvements and standardization come to it.
On Sat, Nov 17, 2012 at 9:06 PM, Brendan Eich bren...@mozilla.org wrote:
Brandon: thanks for
This post is about my experience with the lookup-by-reference and debug
use-cases for Function#name. Both use-cases are very general-purpose--my
examples from Ember.js are just representative examples, and illustrate
ways that we have worked around existing limitations to provide missing
Brandon Benvie wrote:
This is based on
http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions
Justification: the usefulness of the name of function is not just for
debugging. It is useful in the same ways that property names as
strings are such as dispatching by name or
Brendan Eich wrote:
Nit: don't define a baseline and then mutate it. Better to have the
write immutable pd from the get-go, for each case.
Wow, jetlag: Better to have the right immutable pd, I meant.
/be
___
es-discuss mailing list
Whenever a function's name is defined by a Symbol instead of a regular
identifier then the name is the result of ToString(symbol).
Symbols don't have useful ToString conversions, do they? Are you thinking of
the optional string passed to the constructor, for diagnostics and debugging?
The
The language I used was a bit confusing with regards to the baseline and
what does what. In more direct, less spec-like language:
* Function.prototype.name is frozen and set to the empty string.
* named functions of any kind are also frozen and set to the name (how it
currently works in browsers
In regards to Symbols, yeah I was taking for granted them having a usable
value coming ToString that originates from the argument to the constructor.
I imagine that with syntactic support for Symbols this can mostly be
automated by lifting the ToString representation from the Symbol's
declaration.
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
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
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
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
30 matches
Mail list logo
