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

[Mark S. Miller]

On Fri, Jul 2, 2010 at 10:28 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Shades of the first browser wars. This is sometimes the right thing but too
> much and we get tower-of-Babel confusion and extensions that don't go away.
>
> We're not extending SpiderMonkey in Firefox with things not proposed or
> already in the harmony: namespace. We are also not yet agreed on shipping
> Proxy in Firefox 4. It's easy to slap on a vendor prefix, but hard to take
> that away later, and it degrades usability testing subtly.
>

Of the things in the "harmony:" namespace, assuming we find no fatal
conflicts with existing web content, I think we're all happy with "Proxy" as
the name for the object proposed by the proxies proposal.

Regarding "EphemeronTable", we have consensus on the semantics and the API,
but purposely postponed bikeshedding the name at the last meeting when we
decided to promote this from "strawman" to "proposal" status. When I moved
the page from strawman to proposal, I did it with the name of the new global
being "makeEphemeronTable", and with the following paragraph included:

Perhaps as a result of misunderstanding one of Allen's objections, the
proposal below renamed the ephemeron-table-making function from
''EphemeronTable'' to ''makeEphemeronTable'' so that it would not appear to
be a constructor. We seem to have agreement to rename it back to
''EphemeronTable'' if we keep that name for this abstraction. However, many
objected to "ephemeron" as obscure jargon. We have not yet settled the name
we are giving this abstraction.


As it turned out, I did misunderstand Allen's objection. So I've now renamed
it back to "EphemeronTable" and removed all but the last sentence of that
paragraph.

Andreas Gal of Mozilla has been working on an EphemeronTable implementation.
And I have private reason to believe that another implementation may be
proceeding for another JavaScript implementation. Now would be a good time
for the long postponed bikeshedding. 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.



>
> /be
>
> On Jul 2, 2010, at 10:24 AM, Erik Arvidsson wrote:
>
> FYI
>
> Both Mozilla and WebKit have vendor prefixes in DOM extensions.
>
> window.webkitNotifications
> window.mozPaintCount
>
> Chrome added some as well but we use a single object.
>
> chrome.csi();
> chrome.loadTimes()
>
> On Fri, Jul 2, 2010 at 09:23, Allen Wirfs-Brock <
> Allen.Wirfs-Brock at microsoft.com> wrote:
>
>>  I just noticed from John Resig’s Twitter stream that Proxies are now in
>> the FF nightlies.   I think this sort of implementation experience is
>> exactly what we need to be doing for features  that are proposed for
>> Harmony.  However, this announcement starting me thinking about what happens
>> when inevitably there are differences  between this early experimental
>> implementation and the final ES-Harmony specification.   How can we
>> encourage such implementation and usage without also risking premature de
>> facto standardization of details that ultimately may need to change?   Can
>> we help JavaScript programmers recognize such experimental features?
>>
>>
>> This might be done with a technique similar to CSS’s vender-specific
>> naming conventions (eg, _moz_Proxy) or via namespacing.  In either case, we
>> won’t necessary need to use vendor names.  For example, “TC39exp”, is
>> probably a pretty collision safe global name so you might have for example
>> TC39exp.Proxy.
>>
>>
>> I don’t have any personal experience with  CSS vender extensions, but my
>> expression is that they may be somewhat a mixed bag from an interoperability
>> perspective.  Is this the case?  I don’t want to send us down a path that is
>> a folly but it does seem like it would be wise to clearly tag experiments as
>> such.
>>
>>
>> Thoughts?
>>
>>
>> Allen
>>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> erik
>  _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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