> But IIUC, you're proposing a semantics where you construct a brand new object > P whose __proto__ is SuperClass.prototype and then copy all the > own-properties of the RHS into P. > > Not quite. P is a constructor function (class object), SuperClass is a > constructor function. Unless I'm confused, P's ".prototype" is an instance of > SuperClass,
Oh sorry, we're just miscommunicating about what's labeled what -- I was using P to name the .prototype of the subclass constructor. Let me be concrete: class SubClass extends SuperClass RHS I was using P as the name of the new object created and stored as SubClass.prototype. Then P.__proto__ is SuperClass.prototype, and the own-properties of the object that RHS evaluates to are copied into P. Instances O of SubClass have O.__proto__ === P. > and therefore instances of P have an RHS own-property-filled __proto__ object > that itself has a __proto__ object pointing at SuperClass.prototype. Fun > stuff. Wheeee... > Indeed, super() is tricky. For what it's worth, CoffeeScript's class syntax > requires literal (non-expression) class body definitions in part to make > Semantics #4 possible, with purely lexical super calls. Your example's > "LEXICALLYBOUNDPROTO" is CoffeeScript's "ClassObject.__super__". > > Fortunately, y'all have the ability to bend the runtime to your will. To > solve the super() problem, you can simply have the JavaScript engine keep > track of when a function has called through the `super()` boundary, and from > that point on downwards in that method's future call stack, add an extra > `__proto__` lookup to each super resolution. When the inner `super()` is then > called in the context of the outer `this`, the result will be a variant of #2: > > this.__proto__.__proto__.METHODNAME.call(this, ...args) > > ... and it should work. This doesn't sound right to me. What happens if you call the same method on another object while the super-resolution is still active for the first call? IOW, this sounds like it has similar problems to dynamic scope; the behavior of a function becomes sensitive to the context in which it's called, which is unmodular. > There may be something wrong with the above -- but dynamic super() should be > a solveable problem for JS.next, even if not entirely desugar-able into ES3 > terms. The problem isn't so much whether it's possible to come up with a semantics by changing the runtime; I'm sure we could do that. The problem is finding a way to get the semantics you want without taxing the performance all other function calls in the language. (Also known as a "pay-as-you-go" feature: if you don't use the feature, it shouldn't cost you anything.) We don't know how to do that for super(). So I guess in theory I agree it'd be nice if super() and class could be designed completely orthogonally, but in practice they affect each other. But at the same time, I think a class syntax where the body is restricted to be declarative is actually a nice sweet spot anyway. You can still dynamically create classes just like always, but the declarative form gives you a sweet and simple syntax for the most common case. Dave
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss