We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)
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.)
On 2 Jul 2010, at 23:17, 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.)
David
Without meaning to tread on anyone's toes here, from my PoV as someone who doesn't work on any JS engine its the Ephemer{al,on} part that is confusing/obscure.
Is some variation based around "Weak" not possible?
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.
On Fri, Jul 2, 2010 at 3:36 PM, Ash Berlin <ash_js at firemirror.com> wrote:
On 2 Jul 2010, at 23:17, 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.)
DavidWithout meaning to tread on anyone's toes here, from my PoV as someone who doesn't work on any JS engine its the Ephemer{al,on} part that is confusing/obscure.
Is some variation based around "Weak" not possible?
How about
ATableThatDoesWhatManyPeopleThinkWeakKeyTablesDo
;).
More seriously, without prior knowledge of either weak pointers or ephemerons, "ephemeral" seems more self explanatory than "weak".
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.
, Maciej
I'm opposed to anything that contains ephemer* in the name. Most JS developers do not know what this means.
Both WeakMap and CacheMap seems acceptable with a slight favor for WeakMap.
On Fri, Jul 2, 2010 at 16:40, Maciej Stachowiak <mjs at apple.com> wrote:
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.
Yes, I don't think adding Ephemer{on,al}Map without a standard Map is acceptable. I'm also in favor of Set.
I also don't think we should skip Map and Set in favor of Object.hash since it would mean all libraries would have to ship down code to do maps and sets and it would also mean that different libraries would have a harder time to work together due to different Map and Set APIs.
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. Allen?
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 < erights.org/elang/collect/tables.html> <
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 forward!
On Fri, Jul 2, 2010 at 5:48 PM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
I'm opposed to anything that contains ephemer* in the name. Most JS developers do not know what this means.
Both WeakMap and CacheMap seems acceptable with a slight favor for WeakMap.
Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
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.
, Maciej
Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
+1
I <3 WeakMap.
On Jul 2, 2010, at 8:58 PM, David Herman wrote:
Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
+1
I <3 WeakMap.
The Force is strong with WeakMap! ;-)
+1 or more
On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote:
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 erights.org/elang/collect/tables.html, 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 forward!
Ideally TC39 should not standardize or design anything not already proven and popular (if not dominant) in the field. The problem is no one can make practicaly O(1) collections without Object.hashcode and Object.identity.
Say we add hashcode and identity. Then we'll have to wait a while, Could we bootstrap Set, Map, and WeakMap and call it enough? I think so.
"Dense List" could be added but implementations are optimizing for dense arrays already. I think this one is too close to Array to be worth it, but without a detailed design that's just my gut reaction. FWIW.
Coming late to the party: 'alias' might be intuitive (from it's dictionary definition and use in filesystems as a non-preserving way to give an alternate name).
I think WeakMap would be a fine name.
Having make that vote, I'll also say that ObjectMap would also be a fine name. I believe that an "EphemeronTable" is almost always want a app/library developer wants when they want to make an associative mapping keyed by object identity. The exceptional case is actually the one where you don't want the key to be "weak". After all, what good is an association where nobody holds its key?
Seeing as how there were no real objections to WeakMap, we have several "+1" and one even "I <3" (which I just learned means "I heart/love"), I have renamed all non-historic occurrences of EphemeronTable on the wiki to WeakMap. Unless someone objects, I will consider this naming issue closed. Thanks everyone for suggestions and feedback!
On Fri, Jul 2, 2010 at 10:28 AM, Brendan Eich <brendan at mozilla.com> wrote:
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
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>