We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)

Maciej Stachowiak mjs at apple.com
Fri Jul 2 20:04:13 PDT 2010

On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote:

> On Fri, Jul 2, 2010 at 4:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 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.

Indeed, that's what I had in mind when suggesting it. The mapping 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 don't recall precisely enough what anyone's exact position was. I don't recall anyone being firmly opposed to a normal Map, it just didn't seem like a high priority.

I agree that the hash code (and corresponding equivalence relation) should be exposed regardless.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100702/4ad95b69/attachment-0001.html>

More information about the es-discuss mailing list