{Weak|}{Map|Set}

[Allen Wirfs-Brock]

On Sep 15, 2011, at 9:07 AM, Mark S. Miller wrote:

> On Thu, Sep 15, 2011 at 8:47 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> [...]
> 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.
> 
> I do not know of a non-leak-association-map in *any* other language or library whose name does not suggest its GC role. Do you know of a counter-example? If not, then let's say "...burnt by them in every other language...".

Probably not, but in most (if not all cases) those other languages what already used up the "good" names on leaky versions and needed to define more explicit names for the non-leaky versions that were later additions.  We don't have that heritage.  We can do our naming starting from a clean slate. My speculation is that over the long run, many more programmers will be first introduced to these data structures via JS than will come to it after already being corrupted by some other broken language.

> A programmer approaching ES6 wanting simply to make associations and not thinking about GC issues will probably reach for the (iteratable) Map anyway, which is how it should be. For them, the iterability of these maps will often be seen as a virtue. If they are unconcerned about storage, they will usually see little reason to give up on this iterability.

 iterability makes Map inherently leaky from an application logic perspective.  If you place a key in a Map you must manually delete if you don't want to retain it for the full life of the map.  For this reason, the fact that a map is iteratable should probably be featured in its name.  Using "Map" as the name of iteratable associative maps is probably an attractive nuance.  From that perspective, the names I suggest are:
    IteratableMap -->  currently Map, iteratatble associations between arbitrary valued keys and values
    ObjectMap -> currently WeakMap, non-iteratable associations between object valued keys and arbitrary values 

It might be even better to even further increate the conceptual distance between to two abstractions by not using "map" in both names.  In that case, ObjectRegistry might be better than ObjectMap.


> 
>  
> 
> 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.
> 
> Those programmers *should* find our interatable maps, not our weak-association maps.

Only if they need to iterate over them.  If not, the weak association maps is what they should find.

(with the caveat, that I still have concerns about the potential impact of heavy use of ephemeron based maps upon GC performance.)

> 
> 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.
> 
> There are many kinds and levels of programmers. For the typical programmers you talk about, I'd just point them at our current iteratable Maps and Sets.

However, for them, application level leaks are often a problem.  Except for situations where they actually need to iterate they are better served by being pointed towards "WeakMap".




>  
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110915/013ef610/attachment.html>