{Weak|}{Map|Set}

[David Bruant]

Le 15/09/2011 17:47, Allen Wirfs-Brock a écrit :
> On Sep 15, 2011, at 6:49 AM, Andreas Rossberg wrote:
>
>> On 15 September 2011 09:10, Brendan Eich<brendan at mozilla.com>  wrote:
>>> On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote:
>>>
>>>> I would prefer ObjectMap (the keys are restricted to objects).
>>> Now that you point it out (again), I agree.
>> I don't. :) It is true to some extent that WeakMap is GC jargon -- but
>> as Mark points out, the normal use case for weak maps _is_ to ensure a
>> certain space behaviour closely related to GC.
> No the normal use case for WeakMaps is simply to make associations between objects and arbitrary values.  The special GC behavior is necessary to avoid memory leaks, but that is a quality of implementation issue, not a use case.
Furthermore, let imagine for a minute that i need an ECMAScript 
implementation for programs i write which i know (for some reason) all 
are short live and use a maximum finite amount of memory i know. Based 
on this knowledge (i admit this to be weird to have this knowledge), i 
could decide to not implement a garbage collector. My programs are 
short-live and use few memory, i may not need to care about the memory.

In this imagniary ECMAScript environment without Garbage Collection, why 
would i care of references to be weak or strong? I don't, i write programs.


> The typical JS programmer who wants to form such associations is not going to be thinking about the possibility of a leaky map unless they have already been burnt by them in some other language.
They could have been burnt in JS as well for performance reasons.

>> So why obfuscate the
>> very intent by purposely avoiding what is more or less standard
>> terminology for it (if slightly ambiguous)? If I was a programmer
>> looking for something like weak referencing in JS for the first time,
>> "weak" is what I'd be searching for. "ObjectMap" would be too generic
>> a name to catch my immediate attention.
> Because, the majority of JS programmers will simply be looking for a way to "map objects to values" and will not be thinking about GC consequences.  We want them to find this thing we are currently trying to name.  We don't want them to miss it because it has "weak" in its name and they don't know what weak means. We need to design first for the 95% (ass generated number) of JS programmers who don't understand GC.
Also, the notion of garbage collection is a separate concern from 
programming. It comes from the necessity of being careful of resources. 
I recommand this read on the topic: 
http://www.cse.nd.edu/~dthain/courses/cse40243/spring2006/gc-survey.pdf

Ideally, we'd wish memory used by an object to be free'd as soon as we 
don't need the object anymore. Since this notion is clearly undecidable 
(some roulette russe program could make undecidable whether or not an 
object will be used or not later in a program), we have come up with 
restrictions of this notion.
A first naive approach was to count references of an object; when the 
number of reference drops to 0, then the object cannot be accessed 
anymore, consequently, we don't need the memory it uses to be occupied 
anymore and can free the object. The reference counting is tricked by 
reference cycles.
A second approach is to consider that there are some root references and 
traverse the graph of accessible objects. All objects not accessible 
through this graph is not needed anymore since it can be accessed. Once 
again, this approach is a restriction of the general garbage collection 
problem of figuring out whether or not an object is needed in a program.
A third approach could be to dynamically prove that an object won't be 
use even though there would be still references of it in the program.
----
var m = new Map(); // iterable
var o = {};
o.o = o;
m.set(o, true);
var f167 = fibonacci(167); // assumed defined beforehand
----
Since this is my entire program, during the fibonacci call, a (very 
smart) garbage collector could figure out that even though there is a 
living reference to o (o.o or map key) and even though the map is 
iterable the o object can be gabage collected since it won't be used 
anymore. I admit that this kind of proof is very hard to achieve and 
impossible in so many cases. However, even in that context, a program is 
able to free o's memory even without the programmer having to say 
anything about references being weak or strong.

My point is that current state-of-the-art GC technologies rely on 
reference graph traversing. Provinding information to help out the 
traversing algorithm is good, but providing names related to this 
particular help doesn't seem future-proof with regard to future GC 
technologies which may not need this information.

It may also be misleading to implement a so-called "WeakMap" with 
ECMAScript arrays for compatibility reasons [1]. Maybe that WeakMap is 
not really what is needed from the programmer point of view and weak 
references are just a (non-necessary in some cases) convinience rather 
than an actual feature.

David

[1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js