Sorry for dragging this out. The following should be my last email in this 
thread.

> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, 
> b) with extra rules for object return value, which is a complexity. 
> Especially for abstractions that want to be callable without 'new' to 
> construct a new instance (Array, e.g.).

That is complexity that is added to make things compatible with constructor 
functions and current built-ins. If you have to factor that in, then it is 
indeed hard to argue in favor of prototypes-as-classes.

I don’t particularly like that most things are constructed via new, but that in 
a few cases, you can omit the “new” if you want to. I’m also trying to avoid 
the Array constructor (e.g. there is no way to create arrays such as [3] with 
it).

But I do understand that that’s how it is, that people use it and that there is 
nothing one can do about it.

If I summarize my perceived advantages as follows, then it becomes clear that 
they might not be worth the trouble of having two kinds of classes:

(1) Simpler instanceof (Contra: no need to look under the hood)
(2) Simpler subclassing (Contra: not needed very often, super-references make 
most of the advantages go away). Minor inconvenience: having to set up 
C.prototype.constructor in the subclass.
(3) Inheritance of class methods (Contra: I’ve only seen one case where this 
mattered – an inheritance API with an extend() method. Contra: property name 
pollution where constructors are currently used as namespaces).

Looking at these points, it becomes clear that with class literals as syntactic 
sugar, we get all of the advantages of prototypes-as-classes, without their 
disadvantage of having to support two kinds of classes. However, class literals 
are still a move away from the constructor as the dominant construct 
(conceptually, – nothing changes under the hood).

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to