On Jul 2, 2010, at 3:17 PM, David Flanagan wrote: > Mark S. Miller wrote: > However, many objected to "ephemeron" as obscure >> jargon. We have not yet settled the name we are giving this abstraction. > > It is the language of GC implementors, and won't make sense to JS programmers. > >> I'll be happy with almost any name that everyone else can agree to that >> isn't technically incorrect, i.e., not "WeakKeyTable". >> If we can't agree on anything else, I propose that we default to >> "EphemeronTable". It has the virtues of >> * being technically correct >> * giving credit where due >> * unlikely to conflict with any other names in use by legacy JS code. > > 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 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. 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. Regards, Maciej _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
