On Jun 28, 2011, at 12:34 PM, Bob Nystrom wrote: > I like the simplicity of this, but I'm not crazy about how it merges two > distinct objects into one. TodayJS (and most class-based languages) let you > distinguish two things: > > 1. A set of properties relevant to the class itself. > 2. A set of properties shared by each instance of the class.
Yes, and I don't see a good solution to this. From the point of view of utmost simplicity, ignoring history of other languages and of JS itself (not only the built-ins, the DOM and other host object APIs, and user-defined constructor functions), deferring classes wins. But we can't ignore either tradition or user mental models still fostered by function-as-constructor-with-.prototype in JS, which is not going away. The Q&A at http://www.quora.com/How-was-classical-inheritance-*supposed*-to-be-done-in-ECMAScript-3 shows how classical inheritance with class as constructor or factory for instances, not as prototype, has deep roots in developers' minds. Plus, the prototype is in some ways secondary. It's the less directly used object when one calls a constructor often, after populating the prototype. And if class methods come into the picture, the prototype is even more "backstage", an implementation detail. > In a class-based language, #1 up there is "static" methods and fields. So > when you do something like this in Java: > > Integer.parseInt("1234"); > > The "parseInt" method isn't a method that you can call on an integer, it's a > method you call on the Integer class itself. Or perhaps a constructor, if not *the* constructor. Irakli's Ruby-ish .new protocol could help unify how one constructors built-ins and new prototype-first abstractions, but it is not yet proposed, and it is a new protocol (no pun intended). Do we need a second constructor protocol? > Your proposal would allow that, I think. For example, starting from yours: > > // Superclass > var Person = { > constructor: function (name) { > this.name = name; > }, > describe: function() { > return "Person called "+this.name; > } > }; > > I could do: > > var bob = new Person("Bob"); > bob.constructor("Fred"); // I guess I'm Fred now. > > Does the above seem strange to you too? It seems a bit strange to me. One can get used to many things. Probably people could get used to this, but the fact is JS developers are already "used to" constructors with prototypes, where the abstraction's name denotes the constructor, not the prototype. Whatever I personally think, I suspect developers in general, and TC39 in particular, will be divided on this. We can find out the hard way, but I'm pretty sure we won't defer classes in favor of prototypes-first with .constructor as the more backstage object. Grass roots spokes-models also tell me some grumbling against the <| operator hurts this class-free idea. And I note in the font I just used, the | is too tall compared to the <, an aesthetic bad omen. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
