Hi Kyle,
It would be great if we found a name that suggested the full meaning of the
abstraction by itself. "WeakMap" is certainly not that. Sometimes we find
something like this. Also important is one that avoids suggesting any
misunderstandings. I agree that "ObjectMap" beats WeakMap on those grounds.
As to the importance of naming for purpose, which is the contrary argument
here, I have a question for you.
You say "and you're searching for them in JS (as I was)". Had the
abstraction been called ObjectMap or ObjectRegistry, would you have found
it? As it was, you found the right thing to look at and think about, but you
needed to read more before you understood whether it serves your actual
purpose. Was this a better outcome than not finding it?
Other alternate names that were discussed in that thread, listed from my
least to most favorite:
* NonLeakyObjectMap // accurate and suggestive, but a mouthful
* WeakKeyMap // inaccurate, less so than the conclusion Kyle lept to
* EphemeralMap // accurate and suggestive, and far enough from "weak" to
avoid quick misunderstandings
The reason WeakKeyMap is technically inaccurate is that in
var wkm = WeakKeyMap();
var k = {};
wkm.set(k, [k]);
k = null;
the k -> [k] association is no longer reachable. However, because weak key
maps are built on the use of a weak reference to point at the key, and to
receive notification of the key's demise, no weak key map can collect the
above cyclic garbage association.[1] That's what's so important about
ephemerons: the collector knows about such associations, rather than knowing
about the key separately from knowing about the value. That's why I like
"WeakMap" best -- it is the mapping that is weak, not the keys or the
values.
Nevertheless, given the magnitude of misunderstandings people are worried
about here, perhaps this technical inaccuracy is the lesser evil. But my own
preference remains "WeakMap" first and then "EphemeralMap".
[1] wkm holds onto each value strongly until it notices the corresponding
key's demise. In this case, the value holds onto the key strongly, so wkm
has no demise to notice.
On Thu, Sep 15, 2011 at 7:56 AM, Kyle Simpson <get...@gmail.com> wrote:
> 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.
>>
>
> But if you're actually aware of weakrefs (as I am), and you're searching
> for them in JS (as I was), and you see "WeakMap" (as I did), and you make
> the conclusion that "Weak" in the name means in fact weak references (as I
> did), then you probably also (as I did) assume that *all* the refs are weak.
> That's a failed conclusion, because only the keyrefs are weak.
>
> The name doesn't do anything to enlighten you that it only offers weak
> keyrefs and not weak valuerefs -- in fact, by your "discovery" line of
> reasoning, the name is almost a landmine that traps/misleads someone who
> does in fact know about weakrefs -- someone who didn't know about weakrefs
> wouldn't necessarily make the same deductive assumption by seeing "weak" in
> the name.
>
> Misleading/confusing with an API name is, IMHO, worse than less
> implementation-self-**descriptive naming.
>
> --Kyle
>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
