Allen Wirfs-Brock (2015-02-24T01:22:37.000Z)
On Feb 23, 2015, at 4:24 PM, Brendan Eich wrote:

> I wonder why we cannot have toMethod, in due course. You had suggested the ES6 signature with a second parameter, with default value:
> 
>  Function.prototype.toMethod(homeObject, methodName = this.name);
> 
> With a function.name spec'ed in ES6, that might be enough to address the concerns raised by @wycats (among other folks).

I didn't  get into naming issues in this proposal, because it is either (depending upon perspective) a parallel or orthogonal issue.

For a long while functions had a [[MethodName]] internal slot specifically to support property name defaulting in `super` property references and the second argument for toMethod was used to set [[MethodName]]. I don't thing having =this.name as the default was ever in the spec. It's semi-plausable, but during that era, not every super referencing function had a useful 'name' property value.

If we needed to restore [[MethodName]] because we agreed to bring back implicit super() current method name qualification the mixin operator would handle it, an a parallel manner to what it does for [[HomeObject]]. (but the remember, the big concerns about that feature weren't related to how the name was acquired)

Note that the lambda abstraction technique also can support a dynamically provided method name:

let aVarNamedMixin = (obj, name) => obj mixin {
   [name] () {
       //do something
       super[name]()
  }
}

Allen
d at domenic.me (2015-03-06T00:45:42.900Z)
On Feb 23, 2015, at 4:24 PM, Brendan Eich wrote:

> I wonder why we cannot have toMethod, in due course. You had suggested the ES6 signature with a second parameter, with default value:
> 
>  Function.prototype.toMethod(homeObject, methodName = this.name);
> 
> With a function.name spec'ed in ES6, that might be enough to address the concerns raised by @wycats (among other folks).

I didn't  get into naming issues in this proposal, because it is either (depending upon perspective) a parallel or orthogonal issue.

For a long while functions had a [[MethodName]] internal slot specifically to support property name defaulting in `super` property references and the second argument for toMethod was used to set [[MethodName]]. I don't thing having =this.name as the default was ever in the spec. It's semi-plausable, but during that era, not every super referencing function had a useful 'name' property value.

If we needed to restore [[MethodName]] because we agreed to bring back implicit super() current method name qualification the mixin operator would handle it, an a parallel manner to what it does for [[HomeObject]]. (but the remember, the big concerns about that feature weren't related to how the name was acquired)

Note that the lambda abstraction technique also can support a dynamically provided method name:

```js
let aVarNamedMixin = (obj, name) => obj mixin {
   [name] () {
       //do something
       super[name]()
  }
}
```