New private names proposal

[David Herman]

On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:

> 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.

IMO, this is too class-oriented for JS. We should allow the creation of private members of arbitrary objects, not just those that inherit from new constructors. I think it also doesn't address the use case of adding new operations to existing classes like Object or Array without danger of name conflicts.

> Pro's:
> - meaning of private will be more to what people expect

I find this a little hard to believe. It's tricky to make claims about what people will expect. It's true this feels somewhat analogous to Java, but there's a wide diversity of JS programmers. And a lot of them don't want us to just "make it like Java" and do their best to remind us of this fairly regularly. ;)

> - minimal "magic" going on, trying to access a private property out of scope should result in a proper error
> - possibly less impact on the spec (although I'm not sure there...)
> - no need to introduce a new type/class to denote private properties

This last point confuses me -- it sounds like you *have* to introduce a class to denote private properties, because they're associated with a class. Or are you referring to the SoftField type?

Dave