Public/private namespaces in harmony classes proposal

Mark S. Miller erights at
Fri Jul 8 07:15:21 PDT 2011

On Fri, Jul 8, 2011 at 6:36 AM, Juan Ignacio Dopazo
<dopazo.juan at>wrote:

> On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich <brendan at> wrote:
>> On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
>> > Ah, I see.  It's a fair point, but isn't this already a hazard that the
>> language faces?
>> Not with private names.
>> There's also something that was probably discussed but never got to this
> list:
> 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.

> Juan
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list