Just to contribute to this... er... fun-thread... My team uses the closure pattern for our "classes" (i.e. no prototype methods at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g. by making them awkward via manual Name.create(), etc.) will leave that audience behind, still using closures and ignoring any new class sugar. ________________________________ From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Russell Leggett [russell.legg...@gmail.com] Sent: Friday, March 16, 2012 17:07 To: Kevin Smith Cc: es-discuss Subject: Re: Using Object Literals as Classes On Fri, Mar 16, 2012 at 4:26 PM, Kevin Smith <khs4...@gmail.com<mailto:khs4...@gmail.com>> wrote: Thanks, David. First, I'd like to point out that in the blog post I'm putting on the hat of a library author (I happen to be one, but that's beside the point). One of the first conclusions that I come to (as a library author) is that the idiom described here: http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern provides a worse user experience than what I already have. The goal post for any class syntax or idiom is not this: function Blah() Blah.prototype = Object.create(BaseClass.prototype); Blah.prototype.a = function() {}; Blah.prototype.b = function() {}; It is rather this: var MyClass = new Class({ extends: BaseClass, a: function() {}, b: function() {} }); And in the post I conclude fairly early on that the "object extension literal class pattern" described above does not meet or exceed this goal post, not by a long shot. +1, agreed, not by a long shot Now, if object literal extensions were such that I could use them in a "class" library (any class library), then that would be fine. But as indicated in the post, they cannot. The full advantages to be derived from object literal extensions with respect to class construction are *unbreakably bound* to the <| operator. As such <| does not fill in missing low-level pieces of the puzzle, so much as dictate how higher level abstractions must be built. I cannot build a higher level class abstraction from fundamentals without leaking the implementation of that abstraction. The answer cannot be that I ought not build higher level abstractions. If the answer is that we'll have a class syntax, then great. But then we have to ask the related question, should "super" et. all defined on the object literal level? And do we even need special <| or .{} syntax, then? Again, thanks David for reading and replying. I have great respect for everyone's ideas, and I'm just trying to fully explore this one. I am also a library author, and *yes* I've also created yet another class abstraction (seemed like a good idea at the time, 5 years ago) and I have to say, I totally agree. As much as I want to take advantage of <|, its just not good enough at the high or the low level. Because it has to take a literal on the RHS, it can't be used inside a class abstraction library, and because its still so imperative, its not very good at the high level. I think the people that will really be able to take advantage of this will be language designers that target JS. CoffeeScript could probably put this to good use. - Russ kevin _______________________________________________ es-discuss mailing list es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
