On Jun 13, 2014, at 8:05 AM, C. Scott Ananian wrote:

> On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> Jason proposes:
>>    new C(...args) => C[Symbol.new](...args)
>> 
>> Allen proposes:
>>   new C(...args) =>  C.apply(C[Symbol.create](), args)
> 
> Consider also the way the spec could read.  For example, for the
> 'Error' object, instead of having "19.5.1.1 Error ( message )" and
> "19.5.1.2 new Error ( ...argumentsList )", in Jason's formulation
> section 19.5.1.2 would just be "Error[ @@new ]]", aka an ordinary
> method definition.  "If Error is implemented as an ECMAScript function
> object, its inherited implementation of @@new will perform the above
> steps."
> 

The existence or not of @@new doesn't make a difference in that regard.  The only reason we current need the "new Foo(...)" specifications is because [[Construct]] exists and built-ins are not necessarily ECMAScript functions so we have to say what their [[Construct]] behavior is.

If [[Construct]] was eliminated that reason would go away and there would be no need for the "new Foo(...) built-in specifications. 

The only difference between inlining ordinary [[Construct]] into the 'new' operator semantics and defining the 'new' operator as invoking @@new is the amount of freedom anES programmer would have in defining how a @@create method relates to its companion  constructor function. Without @@new there is a fixed protocol for how @@create and the constructor function are invoked relative to each other.  With @@new a different protocol (including ones that completely ignores @@create and the constructor function) could be implemented in ES code. 

It isn't clear if there are really any use cases that could be supported by @@new that couldn't also be support by carefully crafting a @@create and companion constructor function. 

Anotherconcern I have with @@new, it that it exposes two extension points, @@new and @@create, on very constructor.  I'm afraid that it wouldn't be very clear to most ES programmers when you should over-ride one or the other.  

Finally, let's say that for ES6 we eliminate [[Construct]] without adding @@new. If after some experience we find that @@new is really needed we can easily add it in a backwards compatible manner. 

Allen

The existence or not of @@new doesn't make a difference in that regard.  The only reason we current need the "new Foo(...)" specifications is because [[Construct]] exists and built-ins are not necessarily ECMAScript functions so we have to say what their [[Construct]] behavior is.

If [[Construct]] was eliminated that reason would go away and there would be no need for the "new Foo(...) built-in specifications. 

The only difference between inlining ordinary [[Construct]] into the 'new' operator semantics and defining the 'new' operator as invoking @@new is the amount of freedom anES programmer would have in defining how a @@create method relates to its companion  constructor function. Without @@new there is a fixed protocol for how @@create and the constructor function are invoked relative to each other.  With @@new a different protocol (including ones that completely ignores @@create and the constructor function) could be implemented in ES code. 

It isn't clear if there are really any use cases that could be supported by @@new that couldn't also be support by carefully crafting a @@create and companion constructor function. 

Another concern I have with @@new, it that it exposes two extension points, @@new and @@create, on very constructor.  I'm afraid that it wouldn't be very clear to most ES programmers when you should over-ride one or the other.  

Finally, let's say that for ES6 we eliminate [[Construct]] without adding @@new. If after some experience we find that @@new is really needed we can easily add it in a backwards compatible manner.