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 le
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
/be
___
es-discuss mailing list
es-discuss@mozi
> Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
+1
I <3 WeakMap.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote:
> On Fri, Jul 2, 2010 at 4:40 PM, Maciej Stachowiak 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
On Fri, Jul 2, 2010 at 5:48 PM, Erik Arvidsson 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
On Fri, Jul 2, 2010 at 4:40 PM, Maciej Stachowiak 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.
> >
>
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 wrote:
> I'm not sure if there is currently a plan to add a van
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'l
On Fri, Jul 2, 2010 at 3:36 PM, Ash Berlin 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
On Fri, 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
> programm
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 b
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 agr
On Fri, Jul 2, 2010 at 10:28 AM, Brendan Eich 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
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 shippin
I think we should plan for success a bit more than in the past. The CSS vendor
prefixes were supposed to be short-term, but some have persisted without
de-jure standardization, IIRC, for years. That's the downside we can avoid
cleanly by naming per draft spec.
Also, we are not decided yet that
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-br...@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 ine
17 matches
Mail list logo