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

Mark S. Miller erights at google.com
Fri Jul 2 19:45:41 PDT 2010

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

> 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

> Regards,
> Maciej

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

More information about the es-discuss mailing list