new instantiation design alternatives

Dmitry Lomov dslomov at chromium.org
Fri Sep 19 06:14:30 PDT 2014


On Fri, Sep 19, 2014 at 1:25 PM, Kevin Smith <zenparsing at gmail.com> wrote:

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

I am curious why you claim that "constructors of bulit-ins and exotics are
not composable". I believe the current proposal goes a long way towards
composition (via subclassing) of all kinds of constructors (be it bulitins,
exotics, proxies or normal objects).


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

What do you mean by "less functional" here? If in a sense of "functional
language", then I'd argue that starting with a circle and cutting it into
octagon corner by corner is less functional than starting with octagon,
using your colorful metaphors :) (i.e. you imperatively modify the shape of
the primordial object until it becomes Uint8Array - why is this useful?)


> 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?
>

In my view, your "should be"s above should be better motivated. You state
that "Model A" is the right model, even though it does not cover the
exotics (that are with us forever, since we are in the browser) and you
state that future exotics should be compatible with Model A, without
covering the reasons for this. Sure if you believe that Model A is _the
model_, then you are right, but you haven't motivated that belief.

Cheers,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140919/5974c9ba/attachment.html>


More information about the es-discuss mailing list