Private Slots

Kevin Smith khs4473 at gmail.com
Mon Jan 14 13:29:52 PST 2013


> Really, there is nothing new. Try this in your favorite ES5-compliant
> browser:
>
> d = new Date(2000, 0, 1)
> Object.freeze(d)
> d // output: Sat Jan 1 2000 ...
> d.setFullYear(2001)
> d // output: Mon Jan 1 2001 ... Uh? the date was not frozen!
>

This only proves that there is relevant state that is not stored in a
property.  It doesn't prove the existence of private slots, except in a
purely metaphorical sense.

Perhaps self-hosting the built-ins is a valid use-case for private slots.
 But to what extent are private slots necessary for that use case?  Can we
provide for that use case without making the object model more complex?

This is the kind of thing I'm after.

The common reaction I'm seeing (I knew it wouldn't be good!) takes issue
with my assertion that private slots make the object model more complex.

Well they do.

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?

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130114/1a430266/attachment.html>


More information about the es-discuss mailing list