Name of WeakMap

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Name of WeakMap

Erik Arvidsson
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Rick Waldron



On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Mark S. Miller-2
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 <[hidden email]> wrote:



On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Bjoern Hoehrmann
In reply to this post by Erik Arvidsson
* 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:[hidden email] · 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
In reply to this post by Mark S. Miller-2
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 <[hidden email]> 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 <[hidden email]> wrote:



On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:



On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Allen Wirfs-Brock
In reply to this post by Bjoern Hoehrmann

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Oliver Hunt-2
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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Anne van Kesteren
In reply to this post by Andrea Giammarchi-2
On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

David Bruant-5
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Oliver Hunt-2
In reply to this post by Anne van Kesteren
(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 <[hidden email]> wrote:

> On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
> <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Mark S. Miller-2
In reply to this post by Oliver Hunt-2
On Mon, Dec 16, 2013 at 4:42 PM, Oliver Hunt <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

David Bruant-5
In reply to this post by Oliver Hunt-2
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 <[hidden email]> wrote:
>
>> On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
>> <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Tab Atkins Jr.
On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi
<[hidden email]> wrote:
> 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

No, that's not how it works.  You support something as long as
significant amounts of content depend on it, so you don't break pages.
 The existence of a replacement doesn't mean that everyone immediately
updates their pages to the new method.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa.

It would be very unwise to rely prefixed methods only in production and I am not sure who does it but yes, the "dropping" might be gradual notifying in console that has been deprecated.

Having the same unstable, not standard yet, global native constructor is a problem in these fields:
  1. documentation ... MDN has been promoted as "the place to document JavaScript" ... MDN has many Mozilla and Gecko only methods and properties ... does MDN want to include every possible quirk for every possible method that every browser might or might not have implemented in a slightly different, since not standard yet, way? If the answer is NO, it's fragmentation of the documentation ... which I believe is not useful for anyone
  2. User Agent sniffing will be promoted instead of "impossible" features detections
  3. signatures implemented too early will lead to shenanigans
  4. every early implementation either will break the web the day it will change or will create an absurd mess of extra code to understand if it's the one that works as expected or not (again, leads to UA sniffing)
A very concrete example about prefixes, and since you work on this daily, is the CSS gradient background syntax:

Now imagine that scenario with JavaScript ... a constructor that has different signatures and no way to tell if it was an early adoption or the standard version if not through User Agent sniffing ... and since the race to early adopt any sort of thing is the biggest part of "the modern Browsers war", who do you honestly think will benefit from such decision?

I understand that at the time Chromium decided to branch out from WebKit, going to the press saying "yeah, another blok prefix is coming" would have been bad ... press speaking, but at the same time almost nobody uses anymore pure CSS and prefixes there are handled automatically plus many use utilities such lo-dash or others so that behavior are ensured behind the scene and nobody really care if that function was prefixed or not.

What do we have as pros avoiding prefixes instead? Does that overcome all these cons?

Best Regards















On Tue, Dec 17, 2013 at 10:00 AM, Tab Atkins Jr. <[hidden email]> wrote:
On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi
<[hidden email]> wrote:
> 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

No, that's not how it works.  You support something as long as
significant amounts of content depend on it, so you don't break pages.
 The existence of a replacement doesn't mean that everyone immediately
updates their pages to the new method.

~TJ


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Jason Orendorff
On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi
<[hidden email]> wrote:
> The real-world out there always tries to address the potential standard and
> use these prefixed methods as fallbacks, not vice versa.

That's not true.

> almost nobody uses anymore pure CSS and prefixes there are handled automatically

That isn't either.

Not even close.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Andrea Giammarchi-2
Are you able to provide Pros of the non prefixed decision or that's all you have to say about it?

Not even a link?
How useful has your answer been for anyone?

Which library uses window.webkitRequestAnimationFrame before window.requestAnimationFrame and why nobody filed a bug until now?

Plus I am one of those that hand-craft CSS withe prefixes included and I am happy to deal with prefixes ... which developer uses prefixes everywhere on daily basis without tools?

'cause at least I try to group via classes and use as less as possible.

Thanks


On Tue, Dec 17, 2013 at 2:41 PM, Jason Orendorff <[hidden email]> wrote:
On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi
<[hidden email]> wrote:
> The real-world out there always tries to address the potential standard and
> use these prefixed methods as fallbacks, not vice versa.

That's not true.

> almost nobody uses anymore pure CSS and prefixes there are handled automatically

That isn't either.

Not even close.

-j


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Name of WeakMap

Boris Zbarsky
On 12/17/13 6:55 PM, Andrea Giammarchi wrote:
> Which library uses window.webkitRequestAnimationFrame before
> window.requestAnimationFrame and why nobody filed a bug until now?

You have three choices, as a library author.

Either you don't use the unprefixed version, and then your library
somewhat relies on UAs never removing their prefixed versions.

Or you use the unprefixed version after the prefixed version, and then
your library relies on UAs never removing the prefixed version unless
its behavior matches the unprefixed version.

Or you use the unprefixed version first, as you suggest, and then your
library relies on the unprefixed version having the same behavior as the
prefixed version, thus negating the "we can change the behavior"
benefits of prefixing that Oliver brings up.

In practice, option 1 is pretty common.  For example, jQuery 1.10.2 (and
in fact any recent jQuery) does option 1 of these for
Element.moz/ie/webkit/oMatchesSelector (not least because there was no
unprefixed version really specced), which is why we need to support one
of the prefixed versions "forever" (as long as current jQuery versions
are still being used on the web; likely a pretty long time).  Similarly,
jQuery 1.6.1 does the same thing with requestAnimationFrame, falling
back to setTimeout if none of the prefixed versions are supported.  GWT
versions before 2.5 also use option 1 for requestAnimationFrame.

Option 2 is not that uncommon either.  For example, jQuery 1.10.2 uses
it for element.style.foo access: it first tries prefixed versions like
MozFoo and WebKitFoo, before trying foo itself.  Modernizr 2.7.1 does
some of this too, if I read testPropsAll correctly.

Option 3 is sort of used by Prototype 1.7.1.0 for matchesSelector,
though it assumes the unprefixed name will be matchesSelector(), not
matches(), so in practice it's using option 1.  Oh, and it doesn't even
use all the vendor prefixes that are relevant for today's browsers.
Option 3 is also used in thins like
https://gist.github.com/paulirish/1579671 and various other things on
the web.

> Plus I am one of those that hand-craft CSS withe prefixes included and I
> am happy to deal with prefixes ... which developer uses prefixes
> everywhere on daily basis without tools?

A majority of developers working on "mobile" web sites, for example.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12