Public/private namespaces in harmony classes proposal

Juan Ignacio Dopazo dopazo.juan at gmail.com
Fri Jul 8 07:43:35 PDT 2011


On Fri, Jul 8, 2011 at 11:15 AM, Mark S. Miller <erights at google.com> wrote:

> On Fri, Jul 8, 2011 at 6:36 AM, Juan Ignacio Dopazo <dopazo.juan at gmail.com
> > wrote:
>
>> Private instance properties were considered to be accessible by all
>> instances of the class. That's a new concept in ES. Were there arguments for
>> keeping instance private properties private to the instance?
>>
>
> Yes. That's done quite well by lexical capture of the constructor lexical
> context by per-instance methods:
>
>     class Point {
>       constructor(x, y) {
>         public getX() { return x; }
>         ...
>       }
>     }
>
> which basically sugars the objects-as-closure pattern. If you don't mind
> the allocation cost, this is superior in almost all ways to the conventional
> prototype/this-based pattern.
>
> "private" is needed when combining inherited methods with encapsulation.
> Since inherited methods may apply to any instance of the class and are not
> automagically bound to any one instance, their access to encapsulated state
> cannot be any finer than per-class.
>

But when the number of methods that need access to the private property
rises, this becomes a mess of a constructor. And it also breaks the use of
super, doesn't it?

My first thought was: why not just statically replace this.x, with private
x, with this[xPrivateName] and forget about accessing private properties of
other objects? That would still leave the problem of closures inside
methods, though...

Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110708/3ae94952/attachment.html>


More information about the es-discuss mailing list