Ducks, Rabbits, and Privacy

Kevin Smith khs4473 at
Wed Jan 23 07:30:07 PST 2013

> - Hosting getPrivate/setPrivate on Object seems quite strange to me.

Reserve judgement for a bit on this...

> - it seems unrealistic to me to ask developers to write so much code every
> time they want to use their own private instance variable. The notion of
> Private should be specified once for an instance variable, not every time
> it's used internally

Sure - eventually.  But this proposal tries to take a smaller step in that
direction, without committing too much either way.  Also, see the "simple
wrapping API" example in the gist.  The amount of code is quite small if
such a wrapping is used:

    let priv = makePrivate();

    class Purse {

        constructor() {
            priv(this, { balance: 0 });

        getBalance() { return priv(this).balance; }

        makePurse() { return new Purse; }

        deposit(amount, srcPurse) {
            priv(srcPurse).balance -= amount;
            priv(this).balance += amount;

Yes, you have to use the "priv" function.  But on the other hand you don't
need to create (say) 10 private symbols for 10 properties and use ugly
square brackets.

And of course syntax will make all of this more concise in ES7.  And when
it comes time to design ES7, the committee will have more real world usage
to inform the syntax.

> - I haven't followed the whole thread and I'm not a language developer. I
> never felt that I needed a private data structure to hold  internal "stuff".
> One can already do that with a closure and a WeakMap manually if one really
> wants it

Again, I think it might be more convenient to store properties in one
private object, rather than maintain several private symbols.  But that
said, this proposal will allow you to use as many separate symbols as you

> - I do want private instance variables that allow me to truly have
> encapsulation.

Well here ya go! : )

Think of this proposal as a max-min version of privacy.  It leaves WeakMap
as a pure data structure with specific GC semantics (like Allen wants),
while also providing the ability to do efficient rights-amplification (like
Mark wants).  It simplifies the concept of Symbol (there is only one
"kind").  And it leaves a large degree of freedom for future improvements.

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

More information about the es-discuss mailing list