Private Slots

Nathan Wall nathan.wall at live.com
Mon Jan 14 17:18:55 PST 2013


> 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 		 	   		  


More information about the es-discuss mailing list