Why are object initializer methods not usable as constructors?

[/#!/JoePea]

>  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. <jackalmage at gmail.com>
wrote:

> On Wed, Jul 27, 2016 at 11:44 AM, /#!/JoePea <joe at trusktr.io> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160730/58698a4e/attachment-0001.html>