new instantiation design alternatives
dslomov at chromium.org
Fri Sep 19 10:13:14 PDT 2014
Thanks for your thoughtful and argumented response!
On Fri, Sep 19, 2014 at 5:27 PM, Kevin Smith <zenparsing at gmail.com> wrote:
> Thanks Dmitry - great response!
>> 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).
> For example, it is not possible with Model B to take two unrelated
> classes, use one as a base, and mixin the other one (including the
> initialization logic). This is possible with Model A (and ES5 inheritance
> I know that it's possible to do that using the "this=new super" design, by
> proactively branching on "new^" in any class with an extends clause. But I
> believe that this technique is quite painful to write and to that extent
> the design discourages it.
Ah mixins, right!
Well, here is what I think: classes just have to be specially coded for
mixability anyway. For example, all state that they have on instances
should be private state (which we don't yet have). Since some classes are
mixable and some are not (and I argue that most (all?) ES5 classes are not,
because their state is not private), it is a fair requirement that mixable
class constructors are written in mixin-compatible way. It is quite
achievable with the current proposal, although, as you mention, not quite
prettily. I can imagine a syntax extension that will make that easier (e.g.
'this = mixin super(...)').
[Of course it is only your second class that has to be designed to be
mixable. It is pretty straightforward to design it so that if F is not
mixable and G is, you can still get F mixin G to work].
Incidentally, a well-thought-out proposal for mixins in ES7 will be lovely.
> Also, (and I understand that this is an unsupported claim) I believe users
> have very little interest in changing the inheritance model. It's been
>> 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?)
> What if I wanted a Uint8Array that incorporated behavior from some other
> class (which required initialization logic)?
Just from implementation perspective, it is a nightmare to imagine
Uint8Array mixable with AudioBuffer :)
mixability has to be designed).
Hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss