> The distinction between the two was merely semantic in ES5, but now it's mechanical, due to super(); constructing something intended as a method would make super() behave in confusing and unintuitive ways, so methods just don't have a constructor any more.
So, if `super` were dynamic, then it would be no problem. > It's been explained to you already in previous threads why super() is designed the way it is, and how a dynamic super() would add significant cost to some situations Those "some situations" haven't been listed yet (or I don't know where they are listed). Do you know any? As far as I can tell, a dynamic super would perform just fine: - For constructor calls, `HomeObject` can just the `.prototype` property of the function when `new.target` is the same as the function being constructed. That's simple. - If `new.target` is not the current constructed function, then the current function was found on the prototype chain of `Object.getPrototypeOf(new.target)` (i.e. tje `.constructor` property was found on some `HomeObject` in the prototype chain) and then that function is called with the found `HomeObject`. This seems like a simple addition to the property lookup algorithm. - Functions called as methods simply have `HomeObject` passed as the prototype (HomeObject) where they were found. This seems like a simple addition to the property lookup algorithm. - What else? Based on those ideas from my limited knowledge on thetopic, a dynamic `super` doesn't seem to "costly". Suppose I write ```js obj.foo() ``` Then, in ES5, there is already going to be a property lookup algorithm to find `foo` on the prototype chain of `obj`. Therefore, when the property`foo` is found on a prototype (a HomeObject), it doesn't seem like all that much extra cost to simply pass that found object by reference to the `foo` method call, since we already found it. That's not very costly. I may be using the word "HomeObject" wrong, but I think you get what I mean. */#!/*JoePea On Thu, Jul 28, 2016 at 9:11 AM, Tab Atkins Jr. <[email protected]> wrote: > On Wed, Jul 27, 2016 at 11:44 AM, /#!/JoePea <[email protected]> wrote: > > What's the good reason that object-initializer methods can't be > constructors > > though? I mean, I get that "that's what spec says", but what's the actual > > good reason? > > Because they're methods, not functions. The distinction between the > two was merely semantic in ES5, but now it's mechanical, due to > super(); constructing something intended as a method would make > super() behave in confusing and unintuitive ways, so methods just > don't have a constructor any more. > > There are several very similar ways you can write your example that do > achieve what you want. As Allen said, you can just use the non-concise > syntax, explicitly typing "function" (or better, "class") for each of > the values. This is only a few characters more and achieves exactly > what you want. > > It's been explained to you already in previous threads why super() is > designed the way it is, and how a dynamic super() would add > significant cost to some situations. Making this one niche use-case > ("I want to define several constructor-only classes inline in an > object initializer") require a few characters less is not a > sufficiently worthwhile benefit for the cost. Just type the few extra > characters (exactly what you would have typed in ES5, so it's not even > a new imposition), and you'll be fine. > > ~TJ >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
