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<[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
