New private names proposal

[Brendan Eich]

On Dec 22, 2010, at 12:45 PM, Peter van der Zee wrote:

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

Hold this thought ;-).


>>> 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 http://wiki.ecmascript.org/doku.php?id=strawman:private_names
> 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.

Wait, closures can't be used to avoid name collisions when extending existing objects (that held thought).

The new type would be an internal, spec-only thing, were it not for #.id -- that requires typeof #.id == "private name" or some such. It all follows, but it's a hornet's nest in my view. An object subtype (internal  [[Class]] property with new value "PrivateName", e.g.) would be less bitey. Allen's strawman raises this possibility, so it's not really the "hill to die on" -- it's not a big deal over which to shoot down the whole proposal. But it does draw fire that we might prefer held for bigger targets, I agree.

/be