Name of WeakMap
At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
* Erik Arvidsson wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
It seems to me that once again early adoption of non complete standards wins in the short term, compromising the long one forever ... Although IE11 promised incremental updates too and create an alias on the global scope is not the end of the world, IMO. We are all use to write abominations such `var url = window.webkitURL || windows.mozURL || windows.URL` and similar stuff all over, the reason utilities libraries are often preferred, so while I am very happy that IE team finally has been able to catch up and be even in front of other browsers, I do believe that incomplete specifications or those still under discussion should be adopted with prefixes until finalized in their form in order to promote less mistakes in the long term. And yes IE team, the prefix would lowercase as any other Browser is doing, thanks. Just my 2 cents. Best Regards On Mon, Dec 16, 2013 at 9:23 AM, Mark S. Miller erig...@google.com wrote: Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
as the horse rightly pointed out ... please let me reformulate last sentence: And yes IE team, the prefix would be lowercase as any other browser is doing, thanks. ( no MSWhateverItIs, thanks!) On Mon, Dec 16, 2013 at 11:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: It seems to me that once again early adoption of non complete standards wins in the short term, compromising the long one forever ... Although IE11 promised incremental updates too and create an alias on the global scope is not the end of the world, IMO. We are all use to write abominations such `var url = window.webkitURL || windows.mozURL || windows.URL` and similar stuff all over, the reason utilities libraries are often preferred, so while I am very happy that IE team finally has been able to catch up and be even in front of other browsers, I do believe that incomplete specifications or those still under discussion should be adopted with prefixes until finalized in their form in order to promote less mistakes in the long term. And yes IE team, the prefix would lowercase as any other Browser is doing, thanks. Just my 2 cents. Best Regards On Mon, Dec 16, 2013 at 9:23 AM, Mark S. Miller erig...@google.comwrote: Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
The problem i have with SideTable as a name is that it’s implying a very specific use case (one that could equally be served by private names), it’s also not an obvious name to developers who are not aware of terms of art. I said a long time ago that the name WeakMap did not match the expected semantics of other languages, nor what was expected by developers but we couldn’t think of a good alternative name, and (i thought) decided that sticking with WeakMap was the best of the bad options. —Oliver On Dec 16, 2013, at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
Le 16/12/2013 22:42, Anne van Kesteren a écrit : If you're unclear on the name, just make it clear in the specification that the name is not stable and that therefore it cannot ship yet (you could implement it and ship it in nightlies and such of course). Or don't put it in the spec at all? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
(I know Anne knows this argument, but i’m emailing this logic for people who aren’t aware of it) The reason for prefixing APIs is to allow a feature to be shipped and used by developers before the final api semantics are settled on. In the event the spec doesn’t change then they simply alias, but if the spec does change it allows an engine to continue to maintain the old behaviour in the prefixed API and so not break any content that depends on the API. Saying that you should never ship anything if it would need prefixing means that you can never see real examples of usage because no _real_ site is going to use a feature that isn’t available in actual shipping browsers. If the API is not prefixed then once it ships and is used it can never be fixed under the same name (see localStorage being stuck with a string backing store). That’s why prefixed APIs exist — it’s not so we can say the API is unstable, it’s so that the API can be changed once developers have started using preliminary versions. In my opinion the cost of maintaining an old version of the API may be annoying, but is vastly outweighed by the ability to put features in the hands of authors without forcing the API to be stuck with it’s early draft semantics. —Oliver On Dec 16, 2013, at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: We are all use to write abominations such `var url = window.webkitURL || windows.mozURL || windows.URL` and similar stuff all over, the reason utilities libraries are often preferred, so while I am very happy that IE team finally has been able to catch up and be even in front of other browsers, I do believe that incomplete specifications or those still under discussion should be adopted with prefixes until finalized in their form in order to promote less mistakes in the long term. That way you end up with e.g. having to support mozMatchesSelector() forever in addition to matches(). We're certainly going to avoid doing that in Gecko. If you're unclear on the name, just make it clear in the specification that the name is not stable and that therefore it cannot ship yet (you could implement it and ship it in nightlies and such of course). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 4:42 PM, Oliver Hunt oli...@apple.com wrote: The problem i have with SideTable as a name is that it’s implying a very specific use case (one that could equally be served by private names), it’s also not an obvious name to developers who are not aware of terms of art. I said a long time ago that the name WeakMap did not match the expected semantics of other languages, nor what was expected by developers but we couldn’t think of a good alternative name, and (i thought) decided that sticking with WeakMap was the best of the bad options. Several of us, including myself, have been repeatedly surprised at how much confusion the term WeakMap has caused. SideTable may or may not be a bit better, but it doesn't matter. Given existing practice and the lack of a compelling need to rename, it is too late. —Oliver On Dec 16, 2013, at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen, SideTable actually perpetuates most of the confusion caused by the term WeakMap, though not all. SideTable still encourages one to think as-if the mutable storage is in the map/table, rather than being hung off the key objects. That's why it is only a bit better. The Relationship term you mentioned that led to http://wiki.ecmascript.org/doku.php?id=strawman:relationships is still the only term that suggests the right way to think about this, but would be terrible as the name of the abstraction. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
Le 16/12/2013 22:51, Oliver Hunt a écrit : (I know Anne knows this argument, but i’m emailing this logic for people who aren’t aware of it) The reason for prefixing APIs is to allow a feature to be shipped and used by developers before the final api semantics are settled on. In the event the spec doesn’t change then they simply alias, but if the spec does change it allows an engine to continue to maintain the old behaviour in the prefixed API and so not break any content that depends on the API. Saying that you should never ship anything if it would need prefixing means that you can never see real examples of usage because no _real_ site is going to use a feature that isn’t available in actual shipping browsers. This isn't true. Mozilla clearly intends to stop shipping prefixed features. Blink made this very clear too. They both ship unprefixed APIs, but hidden behind a flag and/or in early versions (Canary and Aurora). This systems works well enough, even for real websites whatever you mean by real. Parts of WebRTC are currently only shipped in early browser versions and that allows real people to experiment with it and send feedback before it's considered stable enough to reach the web. If the API is not prefixed then once it ships and is used it can never be fixed under the same name (see localStorage being stuck with a string backing store). That’s why prefixed APIs exist — it’s not so we can say the API is unstable, it’s so that the API can be changed once developers have started using preliminary versions. In my opinion the cost of maintaining an old version of the API may be annoying, but is vastly outweighed by the ability to put features in the hands of authors without forcing the API to be stuck with it’s early draft semantics. :-/ That's also how you end up with de facto standard of webkit prefixes in CSS and the aliasing Opera did before the Chromium-based days. It's likely that the CSS specification will eventually contain the -webkit- properties. This is an unnecessary scar. How web features arrive in stable versions of browsers changed a lot since localStorage. I largely prefer a model without prefix and with early versions. Thanks to Google and Mozilla for their lead in this model! David —Oliver On Dec 16, 2013, at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: We are all use to write abominations such `var url = window.webkitURL || windows.mozURL || windows.URL` and similar stuff all over, the reason utilities libraries are often preferred, so while I am very happy that IE team finally has been able to catch up and be even in front of other browsers, I do believe that incomplete specifications or those still under discussion should be adopted with prefixes until finalized in their form in order to promote less mistakes in the long term. That way you end up with e.g. having to support mozMatchesSelector() forever in addition to matches(). We're certainly going to avoid doing that in Gecko. If you're unclear on the name, just make it clear in the specification that the name is not stable and that therefore it cannot ship yet (you could implement it and ship it in nightlies and such of course). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ES5/ES6 methods on constructor functions instead of prototype
I'm noticing that many methods added in ES5 and due in ES6 are defined on the type's constructor function instead of on the type's prototype. For example, Object.keys, Object.defineProperty, and Array.isArray. Is there a reason these were not added to the prototype, i.e. Object.prototype.keys, for consistency? Best, Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES5/ES6 methods on constructor functions instead of prototype
On Mon, Dec 16, 2013 at 3:24 PM, Oliver Joseph Ash oliverj...@icloud.com wrote: I'm noticing that many methods added in ES5 and due in ES6 are defined on the type's constructor function instead of on the type's prototype. For example, Object.keys, Object.defineProperty, and Array.isArray. Is there a reason these were not added to the prototype, i.e. Object.prototype.keys, for consistency? The Object methods are on the constructor because if they were put on the prototype, they'd show up on every single object in all of JS. The potential for property-name collision would be terrible. Some methods, like isArray(), aren't very useful if they only show up on the prototype - being able to ask an array if it's an Array is nice, but you'd like to be able to ask *any* object. Either you instead define Object.prototype.isArray() (and that still doesn't help primitives, or objects with a null prototype), or you stash it somewhere as a plain function, rather than a method. The Array constructor is a convenient and memorable place to do so - it serves as an adequate namespace for the method to avoid polluting the global object. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
last thought would be an answer to th epossible question:
do we need to support mozMatchSelector forever ?
NO
since matches() will do once it works as standards say
br
On Mon, Dec 16, 2013 at 3:26 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
no prefix and early versions is a mess to feature detect too ... if two
engines offer same name and different signature or functionality you need
to feature detect at runtime which one is correct and this is **not walys
possible**
A clear example is IndexedDB or anything that trigger the ultra-annoying
top thingy in Firefox that asks permission for ... as it is, lately even
for localStorage.
Same name incomplete globals means dealing with a weak User Agent sniffing
over pretending functionality while this means that what is returned
first, is what I can expect and hopefully correct by specs:
`var raf = window.requestAnimationFrame ||
window.mozRequestAnimationFrame;`
I can eventually understand if a prefix was used then decide that if the
non prefixed version is there the behavior of that method or that browser
is X
In this case I don't know if WeakMap is the IE11 one or the partially
implemented in Chrome with experimental flags ... how much difficult all
this has to be for developers?
I thought features detection were the way to go ... unified names with any
sort of early signature adoption on top is a nice theory that does not work
in practice, imho.
We'll see more and more pointless UA sniffing, being unable to know if the
updated version of the same browser did eventually fix that constructor or
not ... not even a [experimental Function] instead of [native Function] as
{}.toString.call I guess, right?
I know there's no perfect solution but prefixes have been a very practical
one that worked.
Libraries can use prefixes once ... browsers can alias final globals with
prefixes without problems, if these where OK so that matches() or
mozMatchSelectos() will be basically the same function.
Best Regards
On Mon, Dec 16, 2013 at 2:07 PM, David Bruant bruan...@gmail.com wrote:
Le 16/12/2013 22:51, Oliver Hunt a écrit :
(I know Anne knows this argument, but i’m emailing this logic for people
who aren’t aware of it)
The reason for prefixing APIs is to allow a feature to be shipped and
used by developers before the final api semantics are settled on. In the
event the spec doesn’t change then they simply alias, but if the spec does
change it allows an engine to continue to maintain the old behaviour in the
prefixed API and so not break any content that depends on the API.
Saying that you should never ship anything if it would need prefixing
means that you can never see real examples of usage because no _real_ site
is going to use a feature that isn’t available in actual shipping browsers.
This isn't true. Mozilla clearly intends to stop shipping prefixed
features. Blink made this very clear too.
They both ship unprefixed APIs, but hidden behind a flag and/or in
early versions (Canary and Aurora). This systems works well enough, even
for real websites whatever you mean by real.
Parts of WebRTC are currently only shipped in early browser versions and
that allows real people to experiment with it and send feedback before
it's considered stable enough to reach the web.
If the API is not prefixed then once it ships and is used it can never
be fixed under the same name (see localStorage being stuck with a string
backing store). That’s why prefixed APIs exist — it’s not so we can say
the API is unstable, it’s so that the API can be changed once developers
have started using preliminary versions.
In my opinion the cost of maintaining an old version of the API may be
annoying, but is vastly outweighed by the ability to put features in the
hands of authors without forcing the API to be stuck with it’s early draft
semantics.
:-/ That's also how you end up with de facto standard of webkit prefixes
in CSS and the aliasing Opera did before the Chromium-based days. It's
likely that the CSS specification will eventually contain the -webkit-
properties. This is an unnecessary scar.
How web features arrive in stable versions of browsers changed a lot
since localStorage. I largely prefer a model without prefix and with early
versions. Thanks to Google and Mozilla for their lead in this model!
David
—Oliver
On Dec 16, 2013, at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
We are all use to write abominations such `var url = window.webkitURL
||
windows.mozURL || windows.URL` and similar stuff all over, the reason
utilities libraries are often preferred, so while I am very happy that
IE
team finally has been able to catch up and be even in front of other
browsers, I do believe that incomplete specifications or those still
under
discussion should be adopted with prefixes
Re: ES5/ES6 methods on constructor functions instead of prototype
How would you define Array.isArray on the Array prototype? That'd just fail for everything that is not an array and doesn't implement isArray itself. Things like Object.keys are reflective, enumerating over the properties of an object (even more so in ES6) is not something you'd commonly do in the 'application level'. We have `Map`s now :) Benjamin -- Forwarded message -- From: Oliver Joseph Ash oliverj...@icloud.com To: es-discuss@mozilla.org Cc: Date: Mon, 16 Dec 2013 23:24:31 + Subject: ES5/ES6 methods on constructor functions instead of prototype I'm noticing that many methods added in ES5 and due in ES6 are defined on the type's constructor function instead of on the type's prototype. For example, Object.keys, Object.defineProperty, and Array.isArray. Is there a reason these were not added to the prototype, i.e. Object.prototype.keys, for consistency? Best, Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
