Hey Dave. On Mon, Oct 31, 2011 at 10:28 PM, David Herman <dher...@mozilla.com> wrote: > > > But with #2 I'm not clear on the intended semantics. You say this could be > desugared but don't provide the details of the desugaring. The RHS is an > arbitrary expression that evaluates to the prototype object (call it P), > but the extends clause is meant to determine P's [[Prototype]], right? Do > you intend to mutate P's [[Prototype]]? I wouldn't agree to that semantics. >
To be a little clearer on the mechanism, it's the basic pattern you get from most libraries that do this sort of thing. We can use goog.inherits as the canonical example: http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.source.html#line1421 class Fox extends Animal { dig: function() {} } Fox becomes a constructor function with a `.prototype` that is set to an instance of Animal that has been constructed without calling the Animal() constructor. (The usual temporary-constructor-to-hold-a-prototype two step shuffle). All of the own properties from the RHS are merged into the empty prototype. The only mutation here is of a brand new object. Animal is not a prototype here, it's a class (constructor function) in its own right. > Another thing that this doesn't address is super(). Right now in ES5 and > earlier, it's pretty painful to call your superclass's constructor: > > In general, I think your arbitrary-expression-RHS design is incompatible > with the super keyword, which needs to be lexically bound to its > class-construction site. I'll have to think about it, though. > super() is a separate (but very much needed) issue -- that should still make it in to JS.next regardless of if a new class syntax does. Likewise, super() calls should not be limited only to objects that have been build with our new classes, they should work with any object that has a prototype (a __proto__). Depending on whether you implement it as a reference to the prototype, or a reference to the prototype's implementation of the current function -- an approach that I would prefer -- the general scheme is: Take the current object's __proto__ and apply the method of the same name there against the current object. If you know the name of the property, and you have the reference to the prototype, I don't see why this would preclude dynamic definitions.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
