Should I be able to apply `new`?

[Graydon Hoare]

Brendan Eich wrote:
> On Apr 6, 2007, at 6:53 AM, Jeff Walden wrote:
> 
>>> function maker () {
>>>    var o = arguments[0].intrinsic::construct.apply(null,  
>>> arguments.slice(1));
>>>    ...
>>>    return o;
>>> }
>> The |null| is purely a guess; I suspect whatever's actually there  
>> is ignored.
> 
> Couple of updates:
> 
> * The hooks for get, set, etc. are in the meta namespace now.
> * We eliminated meta::construct since classes have constructor syntax  
> already, and functions are a single special case.
> * There remain unaddressed use-cases for applyNew or whatever you'd  
> call it (Narcissus calls it __applyConstructor__).

Hold on, he didn't say meta::construct, he said intrinsic::construct.

Eliminating meta::construct is different from eliminating 
intrinsic::construct. The former was the proposed hook for a class to 
override the standard constructor protocol, in rare cases where you want 
to eg. memoize instances rather than allocate new ones.

We decided that's rare enough and confusing enough not to support 
meta::construct; it's easy enough to provide meta::invoke and tell your 
clients to call myClass(...) for such cases, rather than "new 
myClass(...)". We agreed that operator 'new' will always allocate and 
always run the standard construction protocol (inits, settings, ctors, 
in their base/derived nesting order). I don't have a strong opinion for 
or against this position, but it's what the committee concluded at the 
last meeting.

The latter -- intrinsic::construct -- is a function the runtime provides 
to let user code *apply* the standard construction protocol -- as in 
operator 'new' -- to a class and an arguments array. Just as 
Function.apply applies the standard calling protocol to a function and 
an arguments array. IMO we should be providing intrinsic::construct. 
It's in the reference impl at the moment.

-graydon