> Consider again the mixin scenario. A user wants to create a class with
> private methods:
>
> let privateMethod = new Symbol(true);
>
> class C {
> constructor() {}
> [privateMethod]() { }
> publicMethod() { this[privateMethod](); }
> }
>
> And then use that class as a mixin:
>
> class D {
> constructor() { C.call(this); }
> }
>
> mixin(D.prototype, C.prototype);
>
> The footgun fires like this:
>
> new D().publicMethod(); // Error: no [privateMethod] on object
>
> The answer is to use a unique symbol here instead of a private symbol.
> But then [privateMethod] is no longer private. Will the user be
> frustrated by this limitation? And do we really need private slots
> with strict runtime enforcement? Why?
>
This is one thing that came to my mind a couple months ago, but there are a
number of ways to resolve this problem, such as:
function mixin(a, b) {
for (let name of Object.getOwnPropertyNames(b)) {
let desc = Object.getOwnPropertyDescriptor(b, name);
if (typeof desc.value == 'function')
desc.value = desc.value.bind(b);
Object.defineProperty(a, name, desc);
}
}
This, I think, makes a lot of sense with the mixin model because mixins assume
they're going to be working on their own properties anyway and should be pretty
self-contained.
Nathan
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
