Ducks, Rabbits, and Privacy
claus.reinke at talk21.com
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, 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
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