On Sep 15, 2011, at 9:07 AM, Mark S. Miller wrote:
> On Thu, Sep 15, 2011 at 8:47 AM, Allen Wirfs-Brock <[email protected]>
> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
