@@new

[André Bargull]

> > The most important thing here (I agree with Andreas R.) is -- if 
> possible -- avoiding uninitialized object observability.
>
> I agree that uninitialized observability is a pain and has been a 
> on-going source
> of reentrancy bugs in the the more complex built-in constructors. I 
> want to
> explore whether making the constructor arguments available to @@create 
> provides
> an alternative way to eliminate that issue.

That means depending on the class/built-in a subclass needs to override 
either the @@create method or the constructor function or both?

For example let's take the Map built-in. The @@create method will 
initialise [[MapData]] to an empty list early on, that way Map instances 
are never observed uninitialised. Processing the iterable argument to 
fill the Map may either occur in @@create or in the Map constructor 
function. Subclasses will need to consult the specification to find out 
which method needs to be overridden if the iterable argument needs to be 
preprocessed.

For other (more special) built-ins like String/Number/Function/..., 
@@create will need to perform the complete initialisation including 
processing the arguments. Otherwise uninitialised objects are still 
observable. As a result subclasses are required to override @@create and 
overriding the constructor is a no-op (w.r.t. arguments handling).