On Jan 19, 2013, at 8:39 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> ...
>>
>> I like the fact that you used "r" as a name above because certainly a
>> WeakMap can be used to define a relationship involving an immutable object
>> o. But we shouldn't be creating confusion by pretending that those
>> relationships are the samething as a property of o or anyway part of o.
>
> Quite agree.
>
>> ...
>> Well, then we are probably debating about how much we agree with each other.
>> Weakmaps and private Symbols are totally different things. Just because
>> some problems can be solved with either one doesn't make them equivalent.
>
> Agreed, but the live proposal here is to use weakmaps for class private
> instance methods/variables, and not have private symbols.
Then we should be close to resolving that if we agree that WeakMap are
primarily useful for represent external relationships between objects. The
encapsulated state of an object isn't this sort of external relationship and
presumably "private state" is the most intimate form of encapsulated state. It
would be very misleading to both ES programmer and implementors if what
syntactically appears to be private state is specified to have the semantics of
an external relationship.
>
>> But, that said, you certainly could use Weakmaps to define a style of
>> relationship that supports inheritance like mention above. Just create a
>> subclass of Weakmap like:
>>
>> class WeakMapWithKeyInheritance extends Weakmap {
>> has(key) {
>> if (super.has(key)) return true;
>> let proto = Object.getPrototypeOf(key);
>> If (proto === null) return false;
>> return this.has(proto);
>> }
>> get(key) {
>> if (super.has(key)) return super.get(key);
>> let proto = Object.getPrototypeOf(key);
>> If (proto === null) return false;
>> return this.get(proto);
>> }
>> }
>
> Right, but could you have "classes as sugar" including private syntax as
> David proposed (based on weak maps) that can access prototype-delegated
> properties? (I guess they would be 'protected' in that case.)
Yes, its is closer to what "protected" means in some languages and we may want
to add syntax at some point to make it easier to defined private/protected
properties. But it would be a very misleading and unexpected if that syntax
was just sugar for WeakMap operations. Nobody defines private state of a class
with the expectation that it has the implementation cost of maintaining an
external relationship.
Private Symbols and Weakmaps are both useful mechanism that are naturally
optimized for different use cases. We wouldn't be making the world simpler by
requiring that Weakmaps be used for all those use cases.
I tend to be in the same camp as those who say that they only need non-private
Symbols. But I know that there are significant segments of the developer
community who what stronger encapsulation than is offered by reflectable unique
symbols. In particular, I don't see a good way to do strong branding (which
the DOM folks demand) using only non-private Symbols. I don't see regular
WeakMaps as an viable solution to that problem because of the GC impact. We
could try to introduce a separate per instance mechanism for branding, but then
we would have yet another orthogonal feature to integrate (including with
Proxies) . Private symbols, so for, seems like smallest incremental extension
that is a practical solution for the branding use case.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
