New private names proposal

Kyle Simpson getify at
Wed Dec 22 07:27:24 PST 2010

> What about adding an attribute to properties that somehow
> identify which classes (in the prototype chain for protected)
> have access to the object? I'll leave the "somehow" up in the
> air, but you could introduce a [[Private]] attribute which, if not
> undefined, says which context must be set (and for protected,
> either directly or through the prototypal chain of the current
> context) to gain access to this property. And if that context is
> not found, some error is thrown. Maybe it would be
> [[EncapsulationType]] :: {private, protected, public} and
> [[EncapsulationContext]] :: <?>. You could also add a simple api
> to check for these (isPrivate, isProtected, isPublic,
> hasEncapsulatedProperty, etc) depending on how it would affect
> "in" and enumeration.

I’m assuming (perhaps incorrectly) that this suggestion is to model the flag 
of the private vs. non-private as a “property descriptor” that can be set by 
`Object.defineProperty()`. Am I correct?

If so, I think that makes a lot of sense. I would like `private` to work 
that way.

Of course, the setting of `private` would probably have to be one-way, like 
`configurable` is, so that such a property could be made un-private by 
another context.

BTW, pardon (and ignore) me if I just stepped on an ant-bed and confused the 
whole topic. I’ve been following this thread silently and mostly felt like 
it was much more complicated than I could understand. Peter’s post was the 
first one that seemed to make sense. :)


More information about the es-discuss mailing list