On Jun 16, 2014, at 3:02 PM, Jason Orendorff wrote:

> On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> Interesting. It'd be nice if we could further simplify the Proxy/Reflect
>> API. Given the local nature of these changes, we might still include it in
>> ES6 if we achieve quick consensus.
> 
> I'm mostly interested in getting rid of [[Construct]]. Three cheers for that!
> 
> I like @@new better than @@create for three reasons:
> 
> 1. I think it wins on common sense over @@create. "What's this
> Symbol.new thing in this class?" "Oh, whenever you see `new X()`,
> that's shorthand for the @@new method." Pretty straightforward.
> 
> 2. I guess the purpose of @@create, to my mind, was to provide some
> invariants: in particular, an object, once visible to script, is never
> observed to "become" an Array object or "stop being" an Array object.
> Its initialization is hidden in that method. But @@new does that just
> as well or better, it seems to me. "Better" because, well, read on.
> 
> 3. I'm uncomfortable with how all the constructor functions in ES5
> have been rewritten in ES6 to have strange this-value checks and "has
> this value already been initialized? if so, throw" checks.
> Rarely-taken branches are bad for us --- it's a lot of tricky code
> implementers will have to write, test, and optimize, for something
> that should never happen. Providing @@new methods corresponding to the
> ES5 [[Construct]] methods seems more to the point, clearer to specify,
> and easier to implement.
> 

Based upon the above, I don't think I completely misunderstood the semantics you have in mind for @@new.  It sounds like you are saying that  a @@new method would provide all the legacy "as as a constructor behavior" and that the constructor body would provide the legacy "called as a function" behavior.  But presumably to enable:
function f(x) {this.x = x}

to do the expected thing the default @@new behavior would have to call into the regular body of the function.  In that case, aren't you right back with the same problems of trying to  discriminate in a function like f whether it is being called independently or called to initialize something created by @@new?

Perhaps you could fill out what you actually mean by @@new and how it would work for regular functions, class declarations, and subclasses of both regular classes and the legacy built-ins.

Allen

Based upon the above, I don't think I completely misunderstood the semantics you have in mind for @@new.  It sounds like you are saying that  a @@new method would provide all the legacy "as as a constructor behavior" and that the constructor body would provide the legacy "called as a function" behavior.  But presumably to enable:
function f(x) {this.x = x}

to do the expected thing the default @@new behavior would have to call into the regular body of the function.  In that case, aren't you right back with the same problems of trying to  discriminate in a function like f whether it is being called independently or called to initialize something created by @@new?

Perhaps you could fill out what you actually mean by @@new and how it would work for regular functions, class declarations, and subclasses of both regular classes and the legacy built-ins.