>> 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.
>
> There has to be a constructor function somewhere, somehow. The issue is what
> name you invoke it by when calling vs. constructing. With
> constructor-as-class it's the same name, the name of the abstraction denotes
> the constructor. With prototype-as-class, the two diverge -- you call
> C.constructor but you 'new C' (although you can spell out 'new C.constructor'
> too if you like).
Rephrasing my earlier response in reaction to your feedback:
I see it as a separation of concerns:
(1) Instantiation: Create a new instance, give it the proper prototype.
(2) Initialization: Set up the instance variables.
Smalltalk:
(1) Method "new"
(2) Method "initialize"
Prototypes-as-classes (starting from scratch, with a clean protocol that has no
notion of constructor functions):
new C(x,y)
desugars (conceptually!) to
(new C).constructor(x,y)
With:
(1) Instantiation: new C
(2) Initialization: .constructor(x, y)
I find that PaCs untangle (1) and (2), because method constructor() only has to
play role (2), whereas constructor functions have to sometimes play both roles,
sometimes only role (2) (when called from a sub-constructor).
--
Dr. Axel Rauschmayer
[email protected]
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
