Allen Wirfs-Brock (2015-02-24T01:22:37.000Z)
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]() } } ```