On Jun 28, 2011, at 6:33 PM, Axel Rauschmayer wrote: > Sorry for dragging this out. The following should be my last email in this > thread.
Axel, thanks for interacting, nothing to apologize for here. >> 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. 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). > 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). I hate that particular misfeature of Array. > But I do understand that that’s how it is, that people use it and that there > is nothing one can do about it. The Array(length) botch aside, yes: many constructors are callable is functions and they construct in that case too. > 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). It's true, classes want to slide down various lower slopes, over time. The "lint brush" problem, I called it. We on TC39 are obligated to hold the line. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
