On Wed, Jun 18, 2014 at 1:40 AM, David Herman <dher...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
