{Weak|}{Map|Set}
Allen Wirfs-Brock
allen at wirfs-brock.com
Thu Sep 15 08:47:37 PDT 2011
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.
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.
> 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.
Finally, none are good exemplars for typical JS programmers. We (and our friends) know too much and in general have a level of PL expertise that far exceeds that of the typical JS programmer. In cases such as this our expectations may be the exact opposite of a typical JS programmer.
Allen
More information about the es-discuss
mailing list