> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
