Ducks, Rabbits, and Privacy

Claus Reinke claus.reinke at
Tue Jan 22 11:17:32 PST 2013

> It's my opinion that saying that closures should be used for an object 
> to hold onto private data, as you are advocating, is in conflict with ES's
> prototypal model of inheritance. Methods cannot both (A) be on a 
> constructor's prototype and (B) live inside the scope used to house
> private data. The developer is forced to make a decision: Do I want
> my methods to be defined on the constructors prototype or do I 
> want them to have access to private data?

That used to worry me, too, when I came up with my pattern for
implementing (TypeScript-style) private slots via bind[1], but 
currently I think it is inherent (no pun intended;) in private data.

You could have your methods on the prototype and extend/bind 
them from the constructor to give them access to private data.

However, "private" here means instance-private, so if you have
a method that needs access to instance-private data, what is that
going to do on the prototype? You could store it there, but have
to remember to provide it with that instance-private data when 
borrowing it.

This is different from class-private static data, and also from 
"protected" slots, where each object or each method in the 
prototype chain is supposed to have access. I suppose those 
could also be modeled using private symbols - private symbols
do more than just (instance-)private slots.



More information about the es-discuss mailing list