new instantiation design alternatives

Kevin Smith zenparsing at gmail.com
Fri Sep 19 04:25:41 PDT 2014


>
>
> I'm not sure that having two different ways to do subclassing is good.
>

Follow me down the rabbit hole...

I think we all want a unified model of class inheritance.  In ES5, the
model is unified, but only because the built-ins are not truly subclassable.

The ES5 model looks like this:

- Every object starts off with the same undifferentiated shape.  I'm
imagining a circle.
- The constructor is passed the newborn object and is tasked with
differentiating it in whatever manner it sees fit.

Let's call this **Model A**.

This model works really well.  It's simple, flexible, dynamic, and
composable.  Subclassing works via prototype chains and the composability
of constructors.  Ignoring @@create, the current ES6 draft does a beautiful
job of capturing and optimizing this model.

However, it falls short when we try to subclass built-ins and exotics:

- Built-ins and exotics start life with a different and fully
differentiated state.  I'm imagining squares, stars, triangles, and
octagons.
- The constructors of built-ins and exotics are not composable.  Instead of
differentiating objects, they birth objects.

Let's call this **Model B**.

The design introduced by this thread ("this=new super") effectively changes
the inheritance model to match Model B, while supporting Model A as a
legacy feature.  In my opinion, this is a mistake.  It sacrifices the
common case of classes rooted on regular objects to the edge case of
classes rooted on built-ins and exotics.  It makes the ES inheritance model
more fussy and less functional.

In my opinion, constructors conforming to Model B should be considered
legacy cruft.  Model A should be the unified inheritance model going
forward, and new built-ins and exotics should be written to conform to
Model A, or should be future-friendly with Model A.

The class initializer syntax shouldn't be viewed as purely a means of
parent class initialization.  It a general-purpose facility for providing a
"this" value to a constructor when invoked via `new`.  It can be used for
many novel features, one of which is supporting legacy Model B parent
classes.

So, is this "Model A" centered vision plausible?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140919/6abfdf8d/attachment.html>


More information about the es-discuss mailing list