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

[Mark S. Miller]

On Fri, Jul 2, 2010 at 3:17 PM, David Flanagan <david at davidflanagan.com>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?
>

+1. I'd be very happy with that.



>
> 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.)
>

A simple but terribly leaky answer:

const LeakyMap() {
  const et = EphemeralMap();
  const keys = [];
  return Object.freeze({
    get: et.get,
    set: const(key, val) {
      keys.push(key);
      et.set(key, val);
    }
  });
}

Non-leaky answer are easy but not pretty.


>
>        David
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100702/23b97041/attachment-0001.html>