Private Names and Methods

Axel Rauschmayer axel at
Fri Apr 6 14:57:58 PDT 2012

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.

- 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
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list