andre.bargull at udo.edu
Thu Jun 19 06:39:18 PDT 2014
> > 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
> 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
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).
More information about the es-discuss