We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)
mjs at apple.com
Fri Jul 2 16:40:10 PDT 2010
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.
More information about the es-discuss