@@new

[Jason Orendorff]

On Wed, Jun 18, 2014 at 1:40 AM, David Herman <dherman at mozilla.com> wrote:
> You're inlining the method body into the @@new body, but I want to make sure I understand what the specification of the Point function itself would be. You've said Point !== Point[@@new] but calling Point(...args) should behave the same as new Point(...args). So then would the specification of the Point function's behavior just be to delegate to Point[@@new](...args)?

Yes, but that's not central to the proposal.

As it stands in the current draft, Point() would throw a TypeError,
because it tries to set `this.x = x` and `this` would be undefined. We
could keep the semantics exactly as they are even with @@new: just run
the body of the constructor function... It wouldn't be useful though,
just weird. I dunno, the status quo is weird. I don't feel strongly
about this.

>> The "super Arguments" call syntax in the ES6 drafts would be constrained to
>> appear only at the top of a constructor, as in Java:
>
> This part is what I'm the most unclear about. What invariant are you trying to maintain? It seems like you're using this to attempt to guarantee that all superclasses have had the chance to initialize their internal fields before user code starts running, [...]
> But maybe I'm misunderstanding what invariant you're aiming at?

Yeah. I don't care about the new method itself leaking `this`. I just
want to make sure it's *possible* for a class implemented with
reasonable care to initialize its instances fully before exposing
them---and prove it, by making the ES6 builtin classes do so.

I had a syntactic restriction on `super` for two reasons, neither one
related to the kind of invariant you're thinking of: (1) if the
super() call isn't there, I wanted to call it implicitly, for
convenience and correctness-by-default; and, (2) until you call the
base class @@new, there is no `this` value. But the syntactic
restriction isn't sufficient for purpose #2, and besides none of us
like it, so I will try to find another way. :)

>> *   Base class constructors are always called.
>
> Are you saying you would not only restrict the super call to the top, but require one to always be there? Or would an absence of a super call imply an implicit `super()`?

The latter.

>> *   These productions would be dropped from the ES6 grammar:
>>
>>        MemberExpression : new super Arguments
>>        NewExpression : new super
>
> Clearly with your design `super[Symbol.new](...args)` is equivalent to `new super`. Is it also emulate-able in the @@create semantics also?

I think yes, if we drop [[Construct]] as Allen separately proposed. As
long as [[Construct]] exists as a separate internal method, `new
super` is inconvenient to simulate.

> If so it seems like the question of whether to keep or drop the `new super` syntax is 100% orthogonal to your proposal.

I think that's right. I assumed the use cases for `new super` must be
something to do with how objects are constructed now, but on
reflection I don't know what the use cases are.

-j