I was thinking about Allen’s
class Sub extends mixin(Jane, Jack, Super) {
}
Which could have the following prototype chain.
Sub -> Jane' -> Jack' -> Super.prototype
A method in a module that works like Prototype’s Object.extend(), but copies
private properties should suffice.
Variations:
- Copy Jane and Jack into the same object.
- Use a class declaration to define the mixins Jane and Jack. Then the
prototype chain is
Sub -> Jane.prototype' -> Jack.prototype' -> Super.prototype
Quoting Brendan:
> Including the private-named properties? That would be bad for integrity:
> Alice can't give Bob an object-as-capability where the private names stay
> private. Bob can extract them via this hypothetical spread-in-braces and then
> abuse them (e.g. to brand a counterfeit object and fool Carol into thinking
> it was from Alice).
I don’t see how that can be avoided. One could have two kinds of private names:
High-integrity ones and copy-able ones.
On Apr 6, 2012, at 19:42 , Brendan Eich wrote:
> Axel Rauschmayer wrote:
>> Multiple inheritance is where things become interesting. In order to
>> implement some kind of mixin or trait mechanism for JavaScript, you would
>> need the ability to copy private members.
>
> Which .{ can do. The argument is that this is safe against unintended name
> leaks because while the LHS (mixin-derived) is an expression, the RHS
> (mixin-base) is a literal.
>
> Is having only the literal-RHS-only special form too restrictive? It could be
> wrapped in an API usable from downrev script, but this means implementors of
> mixins must use ES6 even though consumers can use pre-ES6.
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
