@@new

[Jason Orendorff]

On Thu, Jun 19, 2014 at 8:39 AM, André Bargull <andre.bargull at udo.edu> wrote:
> 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.

Right. It should happen in the constructor. Map[@@create] can ignore
its arguments and return an empty Map. Subclasses will not need to
override @@create.

> Subclasses will need to consult the specification to find out which method
> needs to be overridden if the iterable argument needs to be preprocessed.

Or just try it and see what happens, which is what people seem to do
in practice. For Map, everything would just work.

However, TC39 could not then evolve Map[@@create] to take arguments in
a later edition. Existing subclasses would rely on Map[@@create]
ignoring its arguments.

> 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).

All correct.  :-|

For a time yesterday, I hoped that @@create + constructor would solve
everything. Classes that need to fully initialize would use @@create;
all other code would use constructor; nobody would have to care which.
But Kevin's right: subclasses would need to care, and it's a burden.

-j