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 today). 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. 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 successful for Javascript, as far as I can tell. > 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)? Think of it like adding to the circle rather than cutting from it. To create a Map (for instance) we take a circle and attach the components necessary for it to function as a Map. The fact that it can function as a Map should not prohibit the user from attaching the raw components necessary for it to function as any other arbitrary class. To implement that in JS, we might use private fields (which we'll hopefully address post-ES6). This is all very beautiful and abstract in my mind : ) I'm interested to know the extent to which it's practical.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss