Function "name" property

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Function "name" property

Matthew Robb
After today's Twitter discussions surrounding babel, concise methods, and a functions name property I had a thought and I was curious if it had been discussed before.

Is there a very good reason that the "name" property of a function is not a well known Symbol property? My understanding is it's main use is for debuggers anyway. It just seems like it would be more in line with the rest of the spec.

​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 writable would help in reducing said confusion.


- Matthew Robb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Allen Wirfs-Brock

On Feb 25, 2015, at 7:26 PM, Matthew Robb <[hidden email]> 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 writable would help in reducing said confusion.

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 delete operator.  You just can’t modify it using the assignment (=) operator.

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Brendan Eich-2
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 standard of sorts, with some
intersection semantics.

/be

Allen Wirfs-Brock wrote:

>
>> On Feb 25, 2015, at 7:26 PM, Matthew Robb <[hidden email]
>> <mailto:[hidden email]>> 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 writable would help in reducing said confusion.
>
> 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
> delete operator.  You just can’t modify it using the assignment (=)
> operator.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Leon Arnott
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()) /* function f() */
```
That is, concise methods cannot seamlessly recursively call or reference themselves. (Personally, I feel like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.)

You may notice that both of the methods above have the same name, "f", in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks this correlation. I don't think this is really an important issue, though - assuming that a `.name` property equated to a binding was not a safe assumption (especially since IE never implemented `.name` but did support the binding).


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Matthew Robb
In reply to this post by Allen Wirfs-Brock

On Wed, Feb 25, 2015 at 11:09 PM, Allen Wirfs-Brock <[hidden email]> 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 delete operator.  You just can’t modify it using the assignment (=) operator.

​My mistake, rather than check the spec I tried it in Chrome's console and the property descriptor was configurable: false.​



- Matthew Robb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Allen Wirfs-Brock
In reply to this post by Leon Arnott

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 this:
```
({ f: function f() { return f; } }.f()) /* function f() */
```
That is, concise methods cannot seamlessly recursively call or reference themselves. (Personally, I feel like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.)

You may notice that both of the methods above have the same name, "f", in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks this correlation. I don't think this is really an important issue, though - assuming that a `.name` property equated to a binding was not a safe assumption (especially since IE never implemented `.name` but did support the binding).

Note that property names are restricted to being valid identifiers.  Note of the following concise methods could possibly use their property name as a lexical binding:

let o = {
  42() {},
  " this is not an identifier"() {},
  ""() {},
  if() {},
  [Symbol.iterate]() {}
};

We may have a universal way for functions to self reference themselves i post ES6.

allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Matthew Robb

On Thu, Feb 26, 2015 at 11:32 AM, Allen Wirfs-Brock <[hidden email]> wrote:
We may have a universal way for functions to self reference themselves i post ES6.

​+1 this!!!!​



- Matthew Robb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Andrea Giammarchi-2
In reply to this post by Allen Wirfs-Brock
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 <[hidden email]> wrote:

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 this:
```
({ f: function f() { return f; } }.f()) /* function f() */
```
That is, concise methods cannot seamlessly recursively call or reference themselves. (Personally, I feel like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.)

You may notice that both of the methods above have the same name, "f", in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks this correlation. I don't think this is really an important issue, though - assuming that a `.name` property equated to a binding was not a safe assumption (especially since IE never implemented `.name` but did support the binding).

Note that property names are restricted to being valid identifiers.  Note of the following concise methods could possibly use their property name as a lexical binding:

let o = {
  42() {},
  " this is not an identifier"() {},
  ""() {},
  if() {},
  [Symbol.iterate]() {}
};

We may have a universal way for functions to self reference themselves i post ES6.

allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Felipe Nascimento de Moura
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 main reason why caller/calee were removed?

Cheers.


On Thu, Feb 26, 2015 at 2:09 PM, Andrea Giammarchi <[hidden email]> wrote:
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 <[hidden email]> wrote:

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 this:
```
({ f: function f() { return f; } }.f()) /* function f() */
```
That is, concise methods cannot seamlessly recursively call or reference themselves. (Personally, I feel like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.)

You may notice that both of the methods above have the same name, "f", in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks this correlation. I don't think this is really an important issue, though - assuming that a `.name` property equated to a binding was not a safe assumption (especially since IE never implemented `.name` but did support the binding).

Note that property names are restricted to being valid identifiers.  Note of the following concise methods could possibly use their property name as a lexical binding:

let o = {
  42() {},
  " this is not an identifier"() {},
  ""() {},
  if() {},
  [Symbol.iterate]() {}
};

We may have a universal way for functions to self reference themselves i post ES6.

allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Felipe N. Moura
Senior Web Developer

Website:  http://felipenmoura.org
Twitter:    @felipenmoura

Meet some of my projects:
BrazilJS Conference  |  BrazilJS Foundation  |  Power Polygon  |  TheWebMind  |  PHPDevBar
---------------------------------
LinuxUser #508332
Changing  the  world  is the least I expect from  myself!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Andrea Giammarchi-2
`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, but `callee` for numerous reasons, and specially for anonymous and non referenced Object methods syntax, is really leaving a hole in the language, IMO

Best Regards

On Thu, Feb 26, 2015 at 5:41 PM, Felipe Nascimento de Moura <[hidden email]> wrote:
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 main reason why caller/calee were removed?

Cheers.


On Thu, Feb 26, 2015 at 2:09 PM, Andrea Giammarchi <[hidden email]> wrote:
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 <[hidden email]> wrote:

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 this:
```
({ f: function f() { return f; } }.f()) /* function f() */
```
That is, concise methods cannot seamlessly recursively call or reference themselves. (Personally, I feel like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.)

You may notice that both of the methods above have the same name, "f", in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks this correlation. I don't think this is really an important issue, though - assuming that a `.name` property equated to a binding was not a safe assumption (especially since IE never implemented `.name` but did support the binding).

Note that property names are restricted to being valid identifiers.  Note of the following concise methods could possibly use their property name as a lexical binding:

let o = {
  42() {},
  " this is not an identifier"() {},
  ""() {},
  if() {},
  [Symbol.iterate]() {}
};

We may have a universal way for functions to self reference themselves i post ES6.

allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Felipe N. Moura
Senior Web Developer

Website:  http://felipenmoura.org
Twitter:    @felipenmoura

Meet some of my projects:
BrazilJS Conference  |  BrazilJS Foundation  |  Power Polygon  |  TheWebMind  |  PHPDevBar
---------------------------------
LinuxUser #508332
Changing  the  world  is the least I expect from  myself!


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Mark S. Miller-2
On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi <[hidden email]> 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 the ability to reach objects you probably shouldn't have.

These two were different beasts, but `callee` for numerous reasons, and specially for anonymous and non referenced Object methods syntax, is really leaving a hole in the language, IMO


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 that are not valid expressions by themselves. ES6 contains the first example of this in "new.target". Many thanks to David Herman for this generalization -- I didn't see it at all.

Note that most of the meta.* proposals I list below I am not advocating -- indeed I think most are probably bad ideas. I include them only as examples of what lexical context meta accesses could be soundly added to the language as special forms.

For the record:


---------- Forwarded message ----------
From: Mark S. Miller <[hidden email]>
Date: Fri, Jan 2, 2015 at 5:10 PM
Subject: Re: Subclassing Builtins


[...] close but not quite. E has a lexical reflective access special form that gives quite a lot of access -- the "meta" keyword. The important features that make it non-objectionable:

a) Its usage patterns is to extract from it the more specific reflective access needed for each use.
b) Its API is designed to encourage such authority division on use.
c) It is understood and documented from the beginning as giving broad access, so hopefully no one will mistake it for providing less access than it does.

So, hypothetically, if, say, we introduced "meta" as such a special form to JS, then

"meta.arguments" could provide arguments.
"meta.originalContructor" could provide the original constructor.
"meta.callee" could provide access to the function it appears in.
"meta.source" could provide access to the source code of the function it appears in.
"meta.strictness" could be a boolean indicating the strictness of the code it appears in.
"meta.environment" could provide a Map from variable name to value reflecting the lexical scope at the place it appears.

More dangerously but still plausibly
"meta" could provide an object with the above fields. The reason it is more dangerous is that passing "meta" might give access to a field added in a later spec. The reason it is still plausible is that passing "meta" itself, unlike passing "arguments" or "meta.arguments", would be understood as passing broad access.

However,
"meta.caller", as something that provide[s] access to the current activation's caller, must still be forbidden.


-- 
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Kevin Smith

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 that are not valid expressions by themselves. 

So, e.g. arguments.callee could be re-imagined as "function.callee" or something similar.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Mark S. Miller-2
yes, exactly. As a lexical special form, it violates no fundamental principle.


On Thu, Feb 26, 2015 at 12:22 PM, Kevin Smith <[hidden email]> 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 contribute towards the syntactic direction we finally took, where allowable new meta-accesses are introduces by <keyword>.<identifier>, but only for keywords that are not valid expressions by themselves. 

So, e.g. arguments.callee could be re-imagined as "function.callee" or something similar.




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Felipe Nascimento de Moura
I remember of a point where it has been discussed about "levels" for the "use strict" flag.
It was discarded, by the way, hehe

But it might be related to this, like "allowing" the detection of calees in the given scope or not.

I think it could be useful like this:
`Function.getMetaData(theFunction);`
to avoid back-compatibility problems

or perhaps, the existence of a new keyword (not so retro-compatible) of a scope.
`
scope.calee;
scope.source;
scope.arguments;
`

ACTUALLY...the word "transient" is reserved in ES, so we could use this keyword, instead of scope...or is this a bad idea?!

I think it is not very cozy to read, something like this
`
function(){
  console.log( function.calee );
  console.log( function.name );
}
`

Regards,


On Thu, Feb 26, 2015 at 5:26 PM, Mark S. Miller <[hidden email]> wrote:
yes, exactly. As a lexical special form, it violates no fundamental principle.


On Thu, Feb 26, 2015 at 12:22 PM, Kevin Smith <[hidden email]> 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 contribute towards the syntactic direction we finally took, where allowable new meta-accesses are introduces by <keyword>.<identifier>, but only for keywords that are not valid expressions by themselves. 

So, e.g. arguments.callee could be re-imagined as "function.callee" or something similar.




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Felipe N. Moura
Senior Web Developer

Website:  http://felipenmoura.org
Twitter:    @felipenmoura

Meet some of my projects:
BrazilJS Conference  |  BrazilJS Foundation  |  Power Polygon  |  TheWebMind  |  PHPDevBar
---------------------------------
LinuxUser #508332
Changing  the  world  is the least I expect from  myself!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Allen Wirfs-Brock
In reply to this post by Mark S. Miller-2
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
 



On Feb 26, 2015, at 12:19 PM, Mark S. Miller wrote:

On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi <[hidden email]> 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 the ability to reach objects you probably shouldn't have.

These two were different beasts, but `callee` for numerous reasons, and specially for anonymous and non referenced Object methods syntax, is really leaving a hole in the language, IMO


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 that are not valid expressions by themselves. ES6 contains the first example of this in "new.target". Many thanks to David Herman for this generalization -- I didn't see it at all.

Note that most of the meta.* proposals I list below I am not advocating -- indeed I think most are probably bad ideas. I include them only as examples of what lexical context meta accesses could be soundly added to the language as special forms.

For the record:


---------- Forwarded message ----------
From: Mark S. Miller <[hidden email]>
Date: Fri, Jan 2, 2015 at 5:10 PM
Subject: Re: Subclassing Builtins


[...] close but not quite. E has a lexical reflective access special form that gives quite a lot of access -- the "meta" keyword. The important features that make it non-objectionable:

a) Its usage patterns is to extract from it the more specific reflective access needed for each use.
b) Its API is designed to encourage such authority division on use.
c) It is understood and documented from the beginning as giving broad access, so hopefully no one will mistake it for providing less access than it does.

So, hypothetically, if, say, we introduced "meta" as such a special form to JS, then

"meta.arguments" could provide arguments.
"meta.originalContructor" could provide the original constructor.
"meta.callee" could provide access to the function it appears in.
"meta.source" could provide access to the source code of the function it appears in.
"meta.strictness" could be a boolean indicating the strictness of the code it appears in.
"meta.environment" could provide a Map from variable name to value reflecting the lexical scope at the place it appears.

More dangerously but still plausibly
"meta" could provide an object with the above fields. The reason it is more dangerous is that passing "meta" might give access to a field added in a later spec. The reason it is still plausible is that passing "meta" itself, unlike passing "arguments" or "meta.arguments", would be understood as passing broad access.

However,
"meta.caller", as something that provide[s] access to the current activation's caller, must still be forbidden.


-- 
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Andrea Giammarchi-2
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 <[hidden email]> 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 considered for ES7
 



On Feb 26, 2015, at 12:19 PM, Mark S. Miller wrote:

On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi <[hidden email]> 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 the ability to reach objects you probably shouldn't have.

These two were different beasts, but `callee` for numerous reasons, and specially for anonymous and non referenced Object methods syntax, is really leaving a hole in the language, IMO


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 that are not valid expressions by themselves. ES6 contains the first example of this in "new.target". Many thanks to David Herman for this generalization -- I didn't see it at all.

Note that most of the meta.* proposals I list below I am not advocating -- indeed I think most are probably bad ideas. I include them only as examples of what lexical context meta accesses could be soundly added to the language as special forms.

For the record:


---------- Forwarded message ----------
From: Mark S. Miller <[hidden email]>
Date: Fri, Jan 2, 2015 at 5:10 PM
Subject: Re: Subclassing Builtins


[...] close but not quite. E has a lexical reflective access special form that gives quite a lot of access -- the "meta" keyword. The important features that make it non-objectionable:

a) Its usage patterns is to extract from it the more specific reflective access needed for each use.
b) Its API is designed to encourage such authority division on use.
c) It is understood and documented from the beginning as giving broad access, so hopefully no one will mistake it for providing less access than it does.

So, hypothetically, if, say, we introduced "meta" as such a special form to JS, then

"meta.arguments" could provide arguments.
"meta.originalContructor" could provide the original constructor.
"meta.callee" could provide access to the function it appears in.
"meta.source" could provide access to the source code of the function it appears in.
"meta.strictness" could be a boolean indicating the strictness of the code it appears in.
"meta.environment" could provide a Map from variable name to value reflecting the lexical scope at the place it appears.

More dangerously but still plausibly
"meta" could provide an object with the above fields. The reason it is more dangerous is that passing "meta" might give access to a field added in a later spec. The reason it is still plausible is that passing "meta" itself, unlike passing "arguments" or "meta.arguments", would be understood as passing broad access.

However,
"meta.caller", as something that provide[s] access to the current activation's caller, must still be forbidden.


-- 
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Mark S. Miller-2
In reply to this post by Allen Wirfs-Brock
On Thu, Feb 26, 2015 at 2:17 PM, Allen Wirfs-Brock <[hidden email]> 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 considered for ES7

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 expect it to be about the lexically enclosing non-arrow function. I do not object to the idea that there be such a special form that is about the arrow function, but it needs to be spelled differently. I have no concrete suggestion though.

But 

function.next -- Current yield result

is awesome! Bravo. It solves a problem which is otherwise really hard to express.


 
--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Allen Wirfs-Brock

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 value passed back via 'next'

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Allen Wirfs-Brock
In reply to this post by Mark S. Miller-2

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 expect it to be about the lexically enclosing non-arrow function. I do not object to the idea that there be such a special form that is about the arrow function, but it needs to be spelled differently. I have no concrete suggestion though.

We have to work with the reserved words we have available,  there really need to apply equivalently to all functions, arrow or otherwise defined.  The only other available keyword that seems at all suggest of these use cases is 'in'

in.callee  (or whatever)
in.count.
in.arguments

If we went that route I'd probably still stick with 'function.next' for that use case

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function "name" property

Jorge Chamorro Bieling
In reply to this post by Leon Arnott
On 26/02/2015, at 13:10, Leon Arnott wrote:

>  Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves,

Not always:

//Yes
a= function f () { return f }; f=null; a()
-> function f()

//No. Look ma, no binding!
function f () { return f }; a=f; f=null; a()
-> null

--
( Jorge )();

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12