New private names proposal

Peter van der Zee ecma at
Wed Dec 22 12:45:01 PST 2010

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

Ok. Indeed it doesn't address adding private properties to any object nor 
extending existing classes, although I think that might be fixable. And you're 
right, it doesn't address 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. ;)

Ok, fair enough.

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

The proposal at 
lists three changes right at the top. 1 is a new type. To me, this seems like a 
rather big impact on the language for introducing something that's already 
possible through closures.

- peter

More information about the es-discuss mailing list