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.
Claus
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-January/028073.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
