Private symbols as WeakMap sugar

generic

 var wm = new WeakMap();
 var o = {};
 o[wm] = 12 // desugars to wm.set(o, 12)
 var a = o[wm]; // desugars to wm.get(o);
 wm in o // desugars to wm.has(o);
 delete o[wm] // desugars to wm.delete(o);

 var w = new WeakMap();
 var o = {};
 o[w] = 37;
 var o2 = Object.create(o);
 console.log(o2[w]); // w.has(o2) returns false, w.has(o) return 

 var w = new WeakMap();
 var ww = new Proxy(w, {});
 var o = {};
 o[ww] = 12; // ww.set(o) calling the ww's set trap?
 // should a/4 new trap(s) be created for internal weakmap methods?
Hi,

This is an idea naturally derived of all the current discussions about 
WeakMaps and Private symbols. The proposal is easily summarized by these 
lines of code:

     var wm = new WeakMap();
     var o = {};
     o[wm] = 12 // desugars to wm.set(o, 12)
     var a = o[wm]; // desugars to wm.get(o);
     wm in o // desugars to wm.has(o);
     delete o[wm] // desugars to wm.delete(o);

# Benefits

## Private symbols are out

No need for the specific freeze behavior.
No need for the unknownPrivateSymbol trap.
Unique symbols do remain though

## MarkM's hint

The use of a different syntax for a different usage would be the hint. 
It's possible that both syntax will be used, but in all likelihood, only 
one syntax will be used per weakmap, clearly indicating to the engine 
which storage and implementation characteristics should be preferred. 
Worst case, the performance of unclear code is a bit worse.

## Inheritance

Both "o[wm]" and "wm in o" could desugar to a slightly more useful 
algorithm involving proto-climbing thus emulating inheritance as we know it.

     var w = new WeakMap();
     var o = {};
     o[w] = 37;
     var o2 = Object.create(o);
     console.log(o2[w]); // w.has(o2) returns false, w.has(o) return 
true. w.get(o); logs 37.

# Downsides

## Object.defineProperty & friends don't work with weakmap as property name

No getter/setter, no configurability, no hasOwnProperty. I see that as a 
benefit actually. YMMV
It makes weakmaps-as-private-symbol inconsistent with unique symbol. I'm 
also ok with this.

## Confusion?

Maybe people will be confused by this bi-use of the same feature. Maybe 
the sugar will result in everyone using it and not caring of 
WeakMap.prototype methods, defeating the "hint" point above.

# Open question

## What happens when the WeakMap is wrapped?

     var w = new WeakMap();
     var ww = new Proxy(w, {});
     var o = {};
     o[ww] = 12; // ww.set(o) calling the ww's set trap?
     // should a/4 new trap(s) be created for internal weakmap methods?

David
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o); 

David Bruant wrote:
> Hi,
>
> This is an idea naturally derived of all the current discussions about 
> WeakMaps and Private symbols. The proposal is easily summarized by 
> these lines of code:
>
>     var wm = new WeakMap();
>     var o = {};
>     o[wm] = 12 // desugars to wm.set(o, 12)
>     var a = o[wm]; // desugars to wm.get(o);
>     wm in o // desugars to wm.has(o);
>     delete o[wm] // desugars to wm.delete(o); 

You are not showing the desugaring in general:

function get(o,x) {
   return o[x];
}

must transform to

function get(o,x) {
   return (x is WeakMap) ? x.get(o) : o[x];
}

This is not an acceptable hit for every []-named property access.

/be
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o); 

Le 16/01/2013 19:42, Brendan Eich a écrit :
> David Bruant wrote:
>> Hi,
>>
>> This is an idea naturally derived of all the current discussions 
>> about WeakMaps and Private symbols. The proposal is easily summarized 
>> by these lines of code:
>>
>>     var wm = new WeakMap();
>>     var o = {};
>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>     var a = o[wm]; // desugars to wm.get(o);
>>     wm in o // desugars to wm.has(o);
>>     delete o[wm] // desugars to wm.delete(o); 
>
> You are not showing the desugaring in general:
>
> function get(o,x) {
>   return o[x];
> }
>
> must transform to
>
> function get(o,x) {
>   return (x is WeakMap) ? x.get(o) : o[x];
> }
You're right, I hadn't thought of that.

> This is not an acceptable hit for every []-named property access.
I intuit (and may be wrong) that even just observing types (weakmap or 
stringified type) passed to a []-access can be a good indicator of how 
best []-named property access should be JIT-compiled. You pay the price 
of the (x is WeakMap) test only the time the JIT warms up.
Given what's in current engines, it sounds doable.

David
On Jan 16, 2013, at 10:53 AM, David Bruant wrote:

> Le 16/01/2013 19:42, Brendan Eich a écrit :
>> David Bruant wrote:
>>> Hi,
>>> 
>>> This is an idea naturally derived of all the current discussions about WeakMaps and Private symbols. The proposal is easily summarized by these lines of code:
>>> 
>>>    var wm = new WeakMap();
>>>    var o = {};
>>>    o[wm] = 12 // desugars to wm.set(o, 12)
>>>    var a = o[wm]; // desugars to wm.get(o);
>>>    wm in o // desugars to wm.has(o);
>>>    delete o[wm] // desugars to wm.delete(o); 
>> 
>> You are not showing the desugaring in general:
>> 
>> function get(o,x) {
>>  return o[x];
>> }
>> 
>> must transform to
>> 
>> function get(o,x) {
>>  return (x is WeakMap) ? x.get(o) : o[x];
>> }
> You're right, I hadn't thought of that.
> 
>> This is not an acceptable hit for every []-named property access.
> I intuit (and may be wrong) that even just observing types (weakmap or stringified type) passed to a []-access can be a good indicator of how best []-named property access should be JIT-compiled. You pay the price of the (x is WeakMap) test only the time the JIT warms up.
> Given what's in current engines, it sounds doable.

If you want to explore this area, I suggest taking a fresh look at http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation 

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130116/72a0b732/attachment.html>
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o); 

David Bruant wrote:
> Le 16/01/2013 19:42, Brendan Eich a écrit :
>> David Bruant wrote:
>>> Hi,
>>>
>>> This is an idea naturally derived of all the current discussions 
>>> about WeakMaps and Private symbols. The proposal is easily 
>>> summarized by these lines of code:
>>>
>>>     var wm = new WeakMap();
>>>     var o = {};
>>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>>     var a = o[wm]; // desugars to wm.get(o);
>>>     wm in o // desugars to wm.has(o);
>>>     delete o[wm] // desugars to wm.delete(o); 
>>
>> You are not showing the desugaring in general:
>>
>> function get(o,x) {
>>   return o[x];
>> }
>>
>> must transform to
>>
>> function get(o,x) {
>>   return (x is WeakMap) ? x.get(o) : o[x];
>> }
> You're right, I hadn't thought of that.
>
>> This is not an acceptable hit for every []-named property access.
> I intuit (and may be wrong) that even just observing types (weakmap or 
> stringified type) passed to a []-access can be a good indicator of how 
> best []-named property access should be JIT-compiled. You pay the 
> price of the (x is WeakMap) test only the time the JIT warms up.
> Given what's in current engines, it sounds doable.

No, it's a hit, pure and simple. Engines do various things, SpiderMonkey 
does semi-static analysis (type inference), but in generic code, you 
propose to add a ?: to every [] operation. I think that's a non-starter. 
I invite others (Andreas R. especially) to weigh in.

/be
Allen Wirfs-Brock wrote:
> If you want to explore this area, I suggest taking a fresh look at 
> http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
How does that help? It does not transpose terms of [] and delegate to 
the left (formerly right) operand.

/be
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o); 

Le 16/01/2013 20:27, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 16/01/2013 19:42, Brendan Eich a écrit :
>>> David Bruant wrote:
>>>> Hi,
>>>>
>>>> This is an idea naturally derived of all the current discussions 
>>>> about WeakMaps and Private symbols. The proposal is easily 
>>>> summarized by these lines of code:
>>>>
>>>>     var wm = new WeakMap();
>>>>     var o = {};
>>>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>>>     var a = o[wm]; // desugars to wm.get(o);
>>>>     wm in o // desugars to wm.has(o);
>>>>     delete o[wm] // desugars to wm.delete(o); 
>>>
>>> You are not showing the desugaring in general:
>>>
>>> function get(o,x) {
>>>   return o[x];
>>> }
>>>
>>> must transform to
>>>
>>> function get(o,x) {
>>>   return (x is WeakMap) ? x.get(o) : o[x];
>>> }
>> You're right, I hadn't thought of that.
>>
>>> This is not an acceptable hit for every []-named property access.
>> I intuit (and may be wrong) that even just observing types (weakmap 
>> or stringified type) passed to a []-access can be a good indicator of 
>> how best []-named property access should be JIT-compiled. You pay the 
>> price of the (x is WeakMap) test only the time the JIT warms up.
>> Given what's in current engines, it sounds doable.
>
> No, it's a hit, pure and simple. Engines do various things, 
> SpiderMonkey does semi-static analysis (type inference), but in 
> generic code, you propose to add a ?: to every [] operation.
I don't understand your point. From the JIT presentations I have watched 
(one per browser vendor except Opera I think) I have understand that JIT 
compilation allows to compile the right efficient things for the + 
operator based on proven (type inference) or observed types. For 
instance, if type information says that the 2 operands of a given + 
operation are strings, then what's compiled is a string concatenation 
without checking types. Likewise if for a given binary +, the 2 operands 
are ints, it's going to be compiled to an addition without the type 
checks/conversions (maybe a guard based on whether types are proven or 
observed)

I think the situation is equivalent to if JS had a binary + only for 
numbers, I was suggesting to use it for string concatenation and you 
were answering "no, all binary + operations will take a hit". Early 
engines probably suffered from that, but the JIT thing I've just 
described has proven that real-life JS code (how does it compare with 
your "generic code"?) can be optimized up-to-native assuming some JIT 
warmup cost.

I feel we're in the exact same situation.
Only code taking the deoptimization paths would take a hit. That would 
be code where the same expression "o[p]" can be used with both strings 
and weakmaps. I don't imagine this becoming the norm.

Am I misunderstanding how JIT compilation using type information works?

> I think that's a non-starter. I invite others (Andreas R. especially) 
> to weigh in.
I'm very interested in implementors opinions indeed.

David
David Bruant wrote:
> Am I misunderstanding how JIT compilation using type information works? 

The problem is not just adding another deoptimization path. Not all JITs 
use only PICs. Lots of optimizations are possible. But adding a ?: to 
the *generic* (I meant what I wrote there) path is not going to fly, in 
my view.

/be
Le 16/01/2013 21:19, Brendan Eich a écrit :
> David Bruant wrote:
>> Am I misunderstanding how JIT compilation using type information works? 
>
> The problem is not just adding another deoptimization path. Not all 
> JITs use only PICs. Lots of optimizations are possible. But adding a 
> ?: to the *generic* (I meant what I wrote there) path is not going to 
> fly, in my view.
I still don't understand what you mean by "generic"? Does it mean adding 
it to the spec algorithm?
And I don't understand why it would be making a situation worse than the 
binary + situation (PIC or not).

David
On Jan 16, 2013, at 11:28 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> If you want to explore this area, I suggest taking a fresh look at http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
> How does that help? It does not transpose terms of [] and delegate to the left (formerly right) operand.

No, but it presents a more general way to make [ ] extensible. And, a @elementGet/@elementSet method, as defined in the proposal, could indeed choose to do that sort of transposition.

If you wanted to "bake-in" this specific Weakmap inverted implementation (about which I'm obviously still quite skeptical) it could be included in the default fall-back behavior that is used if a @elementGet/@elementSet implementation is not found.

Allen
David Bruant wrote:
> Le 16/01/2013 21:19, Brendan Eich a écrit :
>> David Bruant wrote:
>>> Am I misunderstanding how JIT compilation using type information works? 
>>
>> The problem is not just adding another deoptimization path. Not all 
>> JITs use only PICs. Lots of optimizations are possible. But adding a 
>> ?: to the *generic* (I meant what I wrote there) path is not going to 
>> fly, in my view.
> I still don't understand what you mean by "generic"? Does it mean 
> adding it to the spec algorithm?

No, it means any place where PIC overflows due to megamorphism and 
generic code must be used, or TI fails due to too many types or the 
"any" type.

> And I don't understand why it would be making a situation worse than 
> the binary + situation (PIC or not).

See above. Every generic []-operator usage is taxed.

/be
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o);

On 16 January 2013 20:27, Brendan Eich <brendan at mozilla.com> wrote:
> David Bruant wrote:
>>
>> Le 16/01/2013 19:42, Brendan Eich a écrit :
>>>
>>> David Bruant wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is an idea naturally derived of all the current discussions about
>>>> WeakMaps and Private symbols. The proposal is easily summarized by these
>>>> lines of code:
>>>>
>>>>     var wm = new WeakMap();
>>>>     var o = {};
>>>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>>>     var a = o[wm]; // desugars to wm.get(o);
>>>>     wm in o // desugars to wm.has(o);
>>>>     delete o[wm] // desugars to wm.delete(o);
>>>
>>>
>>> You are not showing the desugaring in general:
>>>
>>> function get(o,x) {
>>>   return o[x];
>>> }
>>>
>>> must transform to
>>>
>>> function get(o,x) {
>>>   return (x is WeakMap) ? x.get(o) : o[x];
>>> }
>>
>> You're right, I hadn't thought of that.
>>
>>> This is not an acceptable hit for every []-named property access.
>>
>> I intuit (and may be wrong) that even just observing types (weakmap or
>> stringified type) passed to a []-access can be a good indicator of how best
>> []-named property access should be JIT-compiled. You pay the price of the (x
>> is WeakMap) test only the time the JIT warms up.
>> Given what's in current engines, it sounds doable.
>
> No, it's a hit, pure and simple. Engines do various things, SpiderMonkey
> does semi-static analysis (type inference), but in generic code, you propose
> to add a ?: to every [] operation. I think that's a non-starter. I invite
> others (Andreas R. especially) to weigh in.

Actually, I don't see why this should have a measurable impact on
performance in practice. The "generic" case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
actually seen at runtime. And there, this would just add yet another
row to the (already complex) matrix of cases for receiver/index type
pairs that you optimize for. The same might actually be true for
symbols, depending on the implementation strategy.

Like any new type or representation, it may cause deoptimization and
increased polymorphism, but that's nothing new under the sun, and we
are adding plenty of that with ES6.

/Andreas
Brendan Eich wrote:
> David Bruant wrote:
>> Hi,
>>
>> This is an idea naturally derived of all the current discussions about
>> WeakMaps and Private symbols. The proposal is easily summarized by
>> these lines of code:
>>
>> var wm = new WeakMap();
>> var o = {};
>> o[wm] = 12 // desugars to wm.set(o, 12)
>> var a = o[wm]; // desugars to wm.get(o);
>> wm in o // desugars to wm.has(o);
>> delete o[wm] // desugars to wm.delete(o);
>
> You are not showing the desugaring in general:
>
> function get(o,x) {
> return o[x];
> }
>
> must transform to
>
> function get(o,x) {
> return (x is WeakMap) ? x.get(o) : o[x];
> }

I'd go for genericity here:
   function get(o,x) {
     return x.@@isReversedPseudoProperty ? x[o] : o[x];
   }

combined with OMR which gives WeakMap x[o] ability, it could be generic 
and allow other "reversed getters".

> This is not an acceptable hit for every []-named property access.
>
> /be

Herby
Andreas Rossberg wrote:
> Actually, I don't see why this should have a measurable impact on
> performance in practice. The "generic" case is dog-slow for JavaScript
> anyway, what matters is how easy it is to specialise for the types
> actually seen at runtime. And there, this would just add yet another
> row to the (already complex) matrix of cases for receiver/index type
> pairs that you optimize for. The same might actually be true for
> symbols, depending on the implementation strategy.

Probably I'm more sensitive to the "generic" case, which while dog slow 
still dogs some real-world critical paths (if not fake/lame/old benchmarks).

It all costs, David is proposing yet another cost. Maybe that's my final 
answer :-|.

> Like any new type or representation, it may cause deoptimization and
> increased polymorphism, but that's nothing new under the sun, and we
> are adding plenty of that with ES6.

In contrast, private symbols (any symbols, public/unique or private) 
should benefit from existing property-in-receiver optimizations. Right?

/be
On 17 January 2013 21:08, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>> Actually, I don't see why this should have a measurable impact on
>> performance in practice. The "generic" case is dog-slow for JavaScript
>> anyway, what matters is how easy it is to specialise for the types
>> actually seen at runtime. And there, this would just add yet another
>> row to the (already complex) matrix of cases for receiver/index type
>> pairs that you optimize for. The same might actually be true for
>> symbols, depending on the implementation strategy.
>
> Probably I'm more sensitive to the "generic" case, which while dog slow
> still dogs some real-world critical paths (if not fake/lame/old benchmarks).
>
> It all costs, David is proposing yet another cost. Maybe that's my final
> answer :-|.

I don't know enough about the internals of other VMs, but at least in
V8, the generic case will jump into the C++ runtime (costly) and
potentially trickle through hundreds of lines of logic. I think you
will have a very hard time constructing even a highly artificial
benchmark with which one additional conditional in that logic would be
measurable.

Obviously, that doesn't imply that I consider it a good idea... ;)

>> Like any new type or representation, it may cause deoptimization and
>> increased polymorphism, but that's nothing new under the sun, and we
>> are adding plenty of that with ES6.
>
> In contrast, private symbols (any symbols, public/unique or private) should
> benefit from existing property-in-receiver optimizations. Right?

Perhaps, perhaps not. For V8, we haven't really thought hard yet about
how they fit into the existing representation. They may still end up
requiring a case distinction somewhere.

/Andreas
Le 16 janv. 2013 à 09:11, David Bruant <bruant.d at gmail.com> a écrit :

> Hi,
> 
> This is an idea naturally derived of all the current discussions about WeakMaps and Private symbols. The proposal is easily summarized by these lines of code:
> 
>    var wm = new WeakMap();
>    var o = {};
>    o[wm] = 12 // desugars to wm.set(o, 12)
>    var a = o[wm]; // desugars to wm.get(o);
>    wm in o // desugars to wm.has(o);
>    delete o[wm] // desugars to wm.delete(o);
> 
> <snip>

Hello,

I've just thought of a fundamental flow in the idea of using of weak maps instead of  private symbols, which I believe is enough for forcing to forget that idea, at least on a language design level.

(Note: I have not reread all what have been posted on this list on the subject since then, so I am not sure that someone has not already raised that objection.)

Weak maps and private symbols have completely different goals, and conflating the two features into one can (and, as I'll show,  will) lead to conflict of interest in designing the API. Weak maps are designed for better memory management, while private symbols are designed for better encapsulation. The key difference of philosophy between the two features is:

* In weak maps, you ***need not*** have access to the value if you don't have access to the key.
* With private symbols used as property keys,  you ***must not*** have access to the property value if you don't have access to the symbol.

It is just a happenstance that, in our case "need not" mostly implies "do not". The problem is that it is only "mostly". Indeed:

It is very reasonable to have a -clear() method on WeakMaps, which delete all relations defined by the weak map, in situation where you know that you won't need these mappings any more, but it would be impractical to either enumerate all the keys, or to wipe all references to the weak map. Good for memory management.

On the other hand, you certainly do not want a ".revoke()" method available on every private symbols, which wipe all properties which use that key as private symbol, even on objects to which you are not allowed to have access. Bad for encapsulation.

There is no fundamental problem to use a feature for something very different that it was not designed for. But before sanctioning such a use in a language design, conflict of interest between the two intended use must be carefully considered.

Claude
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a = o[wm]; // desugars to wm.get(o);
wm in o // desugars to wm.has(o);
delete o[wm] // desugars to wm.delete(o);

Le 21/01/2013 10:05, Claude Pache a écrit :
> Le 16 janv. 2013 à 09:11, David Bruant <bruant.d at gmail.com> a écrit :
>
>> Hi,
>>
>> This is an idea naturally derived of all the current discussions about WeakMaps and Private symbols. The proposal is easily summarized by these lines of code:
>>
>>     var wm = new WeakMap();
>>     var o = {};
>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>     var a = o[wm]; // desugars to wm.get(o);
>>     wm in o // desugars to wm.has(o);
>>     delete o[wm] // desugars to wm.delete(o);
>>
>> <snip>
> Hello,
>
> I've just thought of a fundamental flow in the idea of using of weak maps instead of  private symbols, which I believe is enough for forcing to forget that idea, at least on a language design level.
>
> (Note: I have not reread all what have been posted on this list on the subject since then, so I am not sure that someone has not already raised that objection.)
>
> Weak maps and private symbols have completely different goals, and conflating the two features into one can (and, as I'll show,  will) lead to conflict of interest in designing the API. Weak maps are designed for better memory management, while private symbols are designed for better encapsulation. The key difference of philosophy between the two features is:
>
> * In weak maps, you ***need not*** have access to the value if you don't have access to the key.
Although I see it's crucial to understanding your point, I don't 
understand this sentence.

> * With private symbols used as property keys,  you ***must not*** have access to the property value if you don't have access to the symbol.
>
> It is just a happenstance that, in our case "need not" mostly implies "do not". The problem is that it is only "mostly". Indeed:
>
> It is very reasonable to have a -clear() method on WeakMaps, which delete all relations defined by the weak map, in situation where you know that you won't need these mappings any more, but it would be impractical to either enumerate all the keys
It's not possible at all to enumerate weak map keys. The good reason for 
that is that the set of keys depends on GC which is not deterministic (2 
successive enumeration may randomly result in different enumerations).

> or to wipe all references to the weak map. Good for memory management.
Before the clear method, weakmaps had the following property: "you can 
only modify a weakmap entry if you have the key". This property isn't 
true anymore with .clear. This may be considered as abusive ambient 
authority.

> On the other hand, you certainly do not want a ".revoke()" method available on every private symbols, which wipe all properties which use that key as private symbol, even on objects to which you are not allowed to have access. Bad for encapsulation.
I agree for private symbols and I think it equally applies to weak maps.

> There is no fundamental problem to use a feature for something very different that it was not designed for. But before sanctioning such a use in a language design, conflict of interest between the two intended use must be carefully considered.
I agree with you. I starting exploring the idea with the expectation to 
get this kind of feedback. I still thinking of weakmaps with the 
get/set/has/delete interface and the property I mentioned above.

David
Le 21 janv. 2013 à 11:58, David Bruant <bruant.d at gmail.com> a écrit :

> Le 21/01/2013 10:05, Claude Pache a écrit :
>> Le 16 janv. 2013 à 09:11, David Bruant <bruant.d at gmail.com> a écrit :
>> 
>>> Hi,
>>> 
>>> This is an idea naturally derived of all the current discussions about WeakMaps and Private symbols. The proposal is easily summarized by these lines of code:
>>> 
>>>    var wm = new WeakMap();
>>>    var o = {};
>>>    o[wm] = 12 // desugars to wm.set(o, 12)
>>>    var a = o[wm]; // desugars to wm.get(o);
>>>    wm in o // desugars to wm.has(o);
>>>    delete o[wm] // desugars to wm.delete(o);
>>> 
>>> <snip>
>> Hello,
>> 
>> I've just thought of a fundamental flow in the idea of using of weak maps instead of  private symbols, which I believe is enough for forcing to forget that idea, at least on a language design level.
>> 
>> (Note: I have not reread all what have been posted on this list on the subject since then, so I am not sure that someone has not already raised that objection.)
>> 
>> Weak maps and private symbols have completely different goals, and conflating the two features into one can (and, as I'll show,  will) lead to conflict of interest in designing the API. Weak maps are designed for better memory management, while private symbols are designed for better encapsulation. The key difference of philosophy between the two features is:
>> 
>> * In weak maps, you ***need not*** have access to the value if you don't have access to the key.
> Although I see it's crucial to understanding your point, I don't understand this sentence.

The basic idea of weak maps is that, as soon as you have lost explicit reference to some key, it can be garbage-collected. In order to achieve that without exposing GC mechanism, you typically avoid to give access to a key or its corresponding value if you are not able to provide explicitly that key. What I want to say, is that this is a mean, not a requirement (but apparently we disagree on that point, see below).

> 
>> * With private symbols used as property keys,  you ***must not*** have access to the property value if you don't have access to the symbol.
>> 
>> It is just a happenstance that, in our case "need not" mostly implies "do not". The problem is that it is only "mostly". Indeed:
>> 
>> It is very reasonable to have a -clear() method on WeakMaps, which delete all relations defined by the weak map, in situation where you know that you won't need these mappings any more, but it would be impractical to either enumerate all the keys
> It's not possible at all to enumerate weak map keys. The good reason for that is that the set of keys depends on GC which is not deterministic (2 successive enumeration may randomly result in different enumerations).

Instead of "enumerate all the keys", I should have said "explicitly provide all the keys" (without the aid of some inexistent built-in enumeration mechanism).

>> or to wipe all references to the weak map. Good for memory management.
> Before the clear method, weakmaps had the following property: "you can only modify a weakmap entry if you have the key". This property isn't true anymore with .clear. This may be considered as abusive ambient authority.

If indeed this property ("you can only modify a weakmap entry if you have the key") is a goal of WeakMaps, my objection is void. Personally, I consider that property as a mean to achieve another goal, namely garbage collection of keys or values without the need of explicit revocation of the association key/value. But this issue is the subject of your next message ("Questioning WeakMap.prototype.clear"), where it will be more properly discussed.

—Claude

> 
>> On the other hand, you certainly do not want a ".revoke()" method available on every private symbols, which wipe all properties which use that key as private symbol, even on objects to which you are not allowed to have access. Bad for encapsulation.
> I agree for private symbols and I think it equally applies to weak maps.
> 
>> There is no fundamental problem to use a feature for something very different that it was not designed for. But before sanctioning such a use in a language design, conflict of interest between the two intended use must be carefully considered.
> I agree with you. I starting exploring the idea with the expectation to get this kind of feedback. I still thinking of weakmaps with the get/set/has/delete interface and the property I mentioned above.
> 
> David