On Fri, Jul 2, 2010 at 4:40 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Jul 2, 2010, at 3:17 PM, David Flanagan wrote: > [...] > > How about EphemeralMap? > > > > Changing the obscure noun Ephemeron to an adjective reduces the > jargon-level substantially, but retains the three virtues Mark lists. > > > > This name make even more sense to JS programmers if Harmony also > introduced an ordinary Map class for mapping objects to values with regular > strong references. (I assume there is some way to build an ordinary Map on > top of an ephemeron table.) > > I agree that "EphemeronTable" is too jargon-ish and may dissuade developers > from using it. I like Map better than Table as a suffix. Ephemeral is an > improvement, but it sounds like the whole map object is ephemeral, rather > than its mappings. Here are some other ideas: > > WeakMap - doesn't specifically false-advertise as a "weak key" map, but > gets the right idea across > CacheMap - a major use case for this is for "caching" extra data about > objects with automatic cleanup > ExtraDataMap - it's a way to store additional data about objects / values > (in a way that is cleaned up automatically) > I'm happy with all three of these. Interesting point about WeakMap. Not only does it not false advertise, we can even give a rationale about why it is the right name: it is not quite the key that is weak, it is more the mapping that is weak. > I don't think giving credit to inventors should be a major consideration in > API naming. We can give them credit in the spec. > > I'm not sure if there is currently a plan to add a vanilla Map. Some have > suggested that Object.hash is enough, and JS libraries could build on top of > the primitive. Actually, IIRC, that is not anyone's position. Allen was the main advocate for Object.hash and his point is that developers not be stuck with the built-in Map implementation. IIRC, he still did think that there should be some built-in Map implementation even if developers can build alternatives. Allen? > I think it would seem strange to add ephemeron tables without a regular map > data structure too, even if in theory you could build your own. It seems to > me that the standard library of a modern language should include a > reasonable group of fundamental data structures. I would also argue for > adding a hashtable-based Set, but I will concede that is less essential. > I'm also in favour of a regular Map and Set. Also a dense List (i.e., what we might have otherwise called an Array :(.) However, the history of oo class libraries shows collection libraries to be a tarpit, so I'm unwilling to take the lead on this issue. If someone else would like to, so long as they keep it *bloody simple* (i.e., not like Java, Smalltalk, or STL), that'd be great. Even the E collections < http://erights.org/elang/collect/tables.html> < http://erights.org/javadoc/org/erights/e/elib/tables/EMap.html>, where I could make them as simple as I wished, got way too complicated -- more complicated than I would find acceptable. Great designers of extraordinarily simple expressive APIs, please step forward! > > Regards, > Maciej > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
