On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott leonarn...@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
If you want both a TCP-able from and a local (most closely enclosing
callable thing) form then the later should also presumably also be
How about function.sent, to evoke sending a value into the generator via
.next?
On Thu, Feb 26, 2015 at 7:57 PM Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
But
function.next -- Current yield result
is awesome! Bravo. It solves a
On Mar 2, 2015, at 9:22 AM, Rick Waldron wrote:
On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott leonarn...@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
If you want both a TCP-able from and a local (most closely enclosing callable
thing)
On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
If you want both a TCP-able from and a local (most closely enclosing
callable thing) form then the later should also presumably also be
applicable at the top level of functions.
The 'in' meta property prefix in
Andrea Giammarchi wrote:
but how would you drop that listener, if that's even a concern of
yours, beside the usage of `function`?
I'm not addressing your particular issue just yet -- patience!
Does I agree with Mark means already two think arrows function
should never be self-reference-able?
On Feb 28, 2015, at 9:07 AM, Brendan Eich wrote:
No, again, I'm objecting to Allen's just-so story that `function` in an arrow
refers to the arrow, and agreeing with Mark that the pellucid meaning (if
there is one) would be the TCP one: the enclosing function around the arrow
(if there
FWIW `in` looks good to me, it's self explanatory , but `in.self` or
`in.current` don't look god anymore. Would it be utterly insane to have
`in.function` and `function.function` to reference to the function? If
`in.function` works as `function.function` outside arrows, same as
`in.count`
Why do arrow functions need to reflect on themselves? I think it is more
useful for all code directly inside a non-arrow function to be able to
reflect on that non-arrow function. If I wrote an arrow function and then
found I wanted it to reflect on itself, I'd be happier rewriting it as a
On Feb 27, 2015, at 8:00 AM, Rick Waldron wrote:
I was thinking exactly this while I was reading Allen's post.
Would class method definitions use `class.*`? Seems like the wrong
abstraction..? Maybe all functions and method definitions use `function`,
while arrows use `=` (or whatever)
Mark many framewors/libraries/younameit attach listeners at construction
time, there is where everyone feels like it's cool and fast and better, and
shorter to use arrow functions, then they have to mix between removable
listeners and not.
I personally pass objects as listeners, providing an
On Thu Feb 26 2015 at 8:22:55 PM Claude Pache claude.pa...@gmail.com
wrote:
Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a
écrit :
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and
violate no
Rick Waldron wrote:
function Component(target) {
let a = function.arguments;
target.on(click, event = {
// In here, `arguments` refers to the `arguments` object
// that was created for this invocation of Component,
// which makes sense because that object has no sense of
//
On Thu, Feb 26, 2015 at 11:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
We may have a universal way for functions to self reference themselves i
post ES6.
+1 this
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
I miss you `arguments.callee`, specially in this fat arrows era where
most of the time developers don't even care about removing listeners.
Apologies for the laud thought and Best Regards
On Thu, Feb 26, 2015 at 4:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 26, 2015, at 4:10
On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote:
The twitter thread starts here:
https://twitter.com/getify/status/570614952605560838 and basically boils down
to the observation that this:
```
({ f() { return f; }}.f()) /* ReferenceError (probably) */
```
is not semantically identical to
On Wed, Feb 25, 2015 at 11:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The automatically provided ‘name’ property of function objects has the
attributes writable: false, configurable true. That means that its value
can be modified using Object.defineProperty or deleted using the
that's true!
I miss that too!
We are working on a framework for the company here, and sometimes, getting
the callee would be really useful, and we simply can't!!!
Removing the arguments.caller/calee could make more sense if, like other
features, had been replaced by another syntax.
What was the
On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
`callee` could be spec'd similar to `super` and transpiled or resolved
statically instead of dynamically, but `callee.caller` or in general the
function `caller` raised many security concerns, giving you
To respond to this, I searched in vain for the following message on
es-discuss, only to find it in a private thread. This message helped
contribute towards the syntactic direction we finally took, where allowable
new meta-accesses are introduces by keyword.identifier, but only for
keywords
`callee` could be spec'd similar to `super` and transpiled or resolved
statically instead of dynamically, but `callee.caller` or in general the
function `caller` raised many security concerns, giving you the ability to
reach objects you probably shouldn't have.
These two were different beasts,
The twitter thread starts here:
https://twitter.com/getify/status/570614952605560838 and basically boils
down to the observation that this:
```
({ f() { return f; }}.f()) /* ReferenceError (probably) */
```
is not semantically identical to this:
```
({ f: function f() { return f; } }.f()) /*
On Thu, Feb 26, 2015 at 2:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I send a new topic message about the following, but for some reason it
seems slow getting to es-discuss. So, I'm trying it via a replay:
Here is a new proposal for some additional meta properties that should be
I send a new topic message about the following, but for some reason it seems
slow getting to es-discuss. So, I'm trying it via a replay:
Here is a new proposal for some additional meta properties that should be
considered for ES7
https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
FWIW, that looks great to me Allen, thanks for writing that down!
I specially like that it's going to take just about 22 years before
`arguments` will be usable as Array ... eh eh eh, about the time :D
Best Regards
On Thu, Feb 26, 2015 at 10:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
But
function.next -- Current yield result
is awesome! Bravo. It solves a problem which is otherwise really hard to
express.
Actually, another possible name for this that I want to put on the table is:
function.last --- the last
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and violate
no principle, but are they worth it?
I do not like the arrow function behavior. For anything named
function.something occurring within an arrow function, I'd
yes, exactly. As a lexical special form, it violates no fundamental
principle.
On Thu, Feb 26, 2015 at 12:22 PM, Kevin Smith zenpars...@gmail.com wrote:
To respond to this, I searched in vain for the following message on
es-discuss, only to find it in a private thread. This message helped
Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and violate
no principle, but are they worth it?
I do not like the arrow function behavior.
On Feb 25, 2015, at 7:26 PM, Matthew Robb matthewwr...@gmail.com wrote:
...
I think it would be best to put more distance between the name property of a
function and it's binding (if any) to reduce any potential confusion. Making
it a symbol property and (also my opinion) making it
This doesn't address the symbol idea, but I don't see the motivation for
that. A well-known symbol doesn't help usability or integrity. Matthew,
could you please link to the twitter thread?
Anyway, the reason 'name' is a normal property identifier and not a
symbol is because it's a de-facto
According to
http://wiki.ecmascript.org/doku.php?id=harmony:function_name_property ,
This proposal has progressed to the Draft ECMAScript 6 Specification.
I can't seem to find it in 6th Edition / Draft September 27, 2013, though.
Claus
___
es-discuss
On Fri, Oct 11, 2013 at 5:56 AM, Claus Reinke claus.rei...@talk21.comwrote:
According to
http://wiki.ecmascript.org/doku.php?id=harmony:function_name_property ,
This proposal has progressed to the Draft ECMAScript 6 Specification.
I can't seem to find it in 6th Edition / Draft September 27,
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
62 matches
Mail list logo
