Having a non-enumerable Array.prototype.contains may not be web-compatible

[Boris Zbarsky]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it
breaks, for example.

-Boris

[Michał Wadas]

Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/69309c19/attachment-0001.html>

[Boris Zbarsky]

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

I didn't say we need to make it enumerable.

I said that given the current state of the web, a web browser cannot
ship a non-enumerable method named "contains" on Array.prototype.

The options, therefore, are:

1) Make the method enumerable.
2) Name the method something else.
3) Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).

I'm perfectly fine with option 3, personally. Note that in practice
that likely means "never ship it" unless people make some sort of
concerted effort to get sites to update their MooTools version.

-Boris

P.S. It may be worth avoiding the method names mootools sets up but
doesn't force-copy in the future. Even better would be getting them to
fix their code so there are no such method names, of course.

[Andrea Giammarchi]

"the current state of the web" ... with all due respect for that library,
it's been years since I've heard anything about it.

It's also common on the old web to loop over Arrays via `for/in` to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that native prototype would break something else too form
days where `getOwnPropertyNames` was unknown.

long story short: I definitively +1 what Micha? Wadas already said, it's
already patched and people must update software anyway due security
problems, **patches**, etc etc.

just my .02

Post by Boris Zbarsky

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot ship
a non-enumerable method named "contains" on Array.prototype.
1) Make the method enumerable.
2) Name the method something else.
3) Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).
I'm perfectly fine with option 3, personally. Note that in practice that
likely means "never ship it" unless people make some sort of concerted
effort to get sites to update their MooTools version.
-Boris
P.S. It may be worth avoiding the method names mootools sets up but
doesn't force-copy in the future. Even better would be getting them to fix
their code so there are no such method names, of course.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/5c29db5b/attachment.html>

[John-David Dalton]

MooTools breaking because of additions/changes is not a new thing. It has
been broken in the past by things like Function#bind, String#contains, &
Moz removing document.getBoxObjectFor.
Its activity has slowed overall though there is an effort to re-energize
core contributions. Their core has put effort towards another project,
Prime, which does not augment native prototypes.

-JDD

On Tue, Sep 30, 2014 at 12:45 PM, Andrea Giammarchi <

Post by Andrea Giammarchi
"the current state of the web" ... with all due respect for that library,
it's been years since I've heard anything about it.
It's also common on the old web to loop over Arrays via `for/in` to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that native prototype would break something else too form
days where `getOwnPropertyNames` was unknown.
long story short: I definitively +1 what Micha? Wadas already said, it's
already patched and people must update software anyway due security
problems, **patches**, etc etc.
just my .02

Post by Boris Zbarsky

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot ship
a non-enumerable method named "contains" on Array.prototype.
1) Make the method enumerable.
2) Name the method something else.
3) Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).
I'm perfectly fine with option 3, personally. Note that in practice that
likely means "never ship it" unless people make some sort of concerted
effort to get sites to update their MooTools version.
-Boris
P.S. It may be worth avoiding the method names mootools sets up but
doesn't force-copy in the future. Even better would be getting them to fix
their code so there are no such method names, of course.
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/e672893c/attachment.html>

[Oliver Hunt]

The problem is not people actively developing it, or creating new content with it. The problem is _existing_ content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites.

--Oliver

"the current state of the web" ... with all due respect for that library, it's been years since I've heard anything about it.
It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown.
long story short: I definitively +1 what Micha? Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc.
just my .02
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot ship a non-enumerable method named "contains" on Array.prototype.
1) Make the method enumerable.
2) Name the method something else.
3) Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).
I'm perfectly fine with option 3, personally. Note that in practice that likely means "never ship it" unless people make some sort of concerted effort to get sites to update their MooTools version.
-Boris
P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/c7133350/attachment-0001.html>

[Rick Waldron]

Post by Oliver Hunt
The problem is not people actively developing it, or creating new content
with it. The problem is _existing_ content that might break. All libraries
have periods where they are in vogue, and then fade out leaving detritus
that hangs around for years/decades on major sites.

In these cases, evangelism over the next two years will help. Most major
sites are also maintained sites, which means there is time to work on
getting the necessary fixes implemented.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/b2c6f260/attachment.html>

[Andrea Giammarchi]

I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Should ES7 be planned around all methods already taken in there? I don't
think so + it is also already patched and it's also a small fix.

If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Best Regards

Post by Oliver Hunt
The problem is not people actively developing it, or creating new content
with it. The problem is _existing_ content that might break. All libraries
have periods where they are in vogue, and then fade out leaving detritus
that hangs around for years/decades on major sites.
--Oliver
On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi <
"the current state of the web" ... with all due respect for that library,
it's been years since I've heard anything about it.
It's also common on the old web to loop over Arrays via `for/in` to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that native prototype would break something else too form
days where `getOwnPropertyNames` was unknown.
long story short: I definitively +1 what Micha? Wadas already said, it's
already patched and people must update software anyway due security
problems, **patches**, etc etc.
just my .02

Post by Boris Zbarsky

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot ship
a non-enumerable method named "contains" on Array.prototype.
1) Make the method enumerable.
2) Name the method something else.
3) Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).
I'm perfectly fine with option 3, personally. Note that in practice that
likely means "never ship it" unless people make some sort of concerted
effort to get sites to update their MooTools version.
-Boris
P.S. It may be worth avoiding the method names mootools sets up but
doesn't force-copy in the future. Even better would be getting them to fix
their code so there are no such method names, of course.
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/6bc7b7ba/attachment-0001.html>

[Jason Orendorff]

On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

-j

[Rick Waldron]

On Tue, Sep 30, 2014 at 7:24 PM, Jason Orendorff <jason.orendorff at gmail.com>

Post by Jason Orendorff
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's

not

Post by Andrea Giammarchi
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

I support your decision to back it out for now and the foreseeable future.
This will give devs a chance to evangelize the necessary updates.

Rick

Post by Jason Orendorff

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.
That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.
-j
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/b44469ca/attachment.html>

[John-David Dalton]

So put ES7 features behind a flag until the water clears a bit. We'll get
there.
It kind of surprises me (a good surprise) that now, because of JSFiddle,
there's super interest in MooTools. When in the past, when MooTools was
arguably more popular, it didn't stop the language and browsers from
breaking them over and over again.

JDD

On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff <jason.orendorff at gmail.com>

Post by Jason Orendorff
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's

not

Post by Andrea Giammarchi
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.
That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.
-j
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/ce142e2a/attachment-0001.html>

[Domenic Denicola]

You guys are much more optimistic than I am about this ever being shippable. I am starting a new thread to investigate solutions that don?t involve waiting for indeterminate amounts of time, but of course if we can somehow fix the MooTools-using web and not change anything about Array.prototype.contains, that would be ideal.

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of John-David Dalton
Sent: Wednesday, October 1, 2014 00:55
To: Jason Orendorff
Cc: es-discuss
Subject: Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

So put ES7 features behind a flag until the water clears a bit. We'll get there.
It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again.

JDD

On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff <jason.orendorff at gmail.com<mailto:jason.orendorff at gmail.com>> wrote:
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

-j
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/6d98c615/attachment.html>

[Andrea Giammarchi]

many MDN examples are on jsfiddle ...maybe one of the reasons? Although I wasn't suggesting to break everything, rather saying that changing name should not be an option.

-----Original Message-----
From: "John-David Dalton" <john.david.dalton at gmail.com>
Sent: ?01/?10/?2014 00:54
To: "Jason Orendorff" <jason.orendorff at gmail.com>
Cc: "Andrea Giammarchi" <andrea.giammarchi at gmail.com>; "es-discuss" <es-discuss at mozilla.org>
Subject: Re: Having a non-enumerable Array.prototype.contains may not beweb-compatible

So put ES7 features behind a flag until the water clears a bit. We'll get there.

It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again.


JDD


On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff <jason.orendorff at gmail.com> wrote:

On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

-j

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/a6942e74/attachment.html>

[Andrea Giammarchi]

FYI: from a MooTools core developer:
https://gist.github.com/fakedarren/28953b01e455078fb4f8

Just to close this chapter/thread with some external outcome.


Regards

On Wed, Oct 1, 2014 at 7:56 AM, Andrea Giammarchi <

Post by Andrea Giammarchi
many MDN examples are on jsfiddle ...maybe one of the reasons? Although I
wasn't suggesting to break everything, rather saying that changing name
should not be an option.
------------------------------
From: John-David Dalton <john.david.dalton at gmail.com>
Sent: ?01/?10/?2014 00:54
To: Jason Orendorff <jason.orendorff at gmail.com>
Cc: Andrea Giammarchi <andrea.giammarchi at gmail.com>; es-discuss
<es-discuss at mozilla.org>
Subject: Re: Having a non-enumerable Array.prototype.contains may not beweb-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get there.
It kind of surprises me (a good surprise) that now, because of JSFiddle,
there's super interest in MooTools. When in the past, when MooTools was
arguably more popular, it didn't stop the language and browsers from
breaking them over and over again.
JDD
On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff <

Post by Jason Orendorff
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi

Post by Andrea Giammarchi
I'm personally against unmaintained code and/or websites but here it's

not

Post by Andrea Giammarchi
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

Post by Andrea Giammarchi
it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

Post by Andrea Giammarchi
If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.
That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.
-j
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141007/3e4805c3/attachment.html>

[Garrett Smith]

Old sites with old version of Mootools will have problems when trying
to use native Array.prototype.contains. Is that the only problem or is
there something else I'm missing?

Post by Andrea Giammarchi
https://gist.github.com/fakedarren/28953b01e455078fb4f8

The article has a few issues. Array.prototype.forEach landed in
Mozilla before 2006, and there are still libraries that modify DOM
prototypes. Polymer, by the former Bindows author, is one. Modifying
built-in Array.prototype for GP scripts was never a good idea. And
the gist misses the big point that modifying objects that you don't
own, you risk issues with forwards compatibility. Here it is now, at
forward compatibility issue point. The ideas were bad at the time. I
criticized them pretty heavily around 2007 for these ideas and they
complained on my blog. Now, they are congratulating themselves on
their efforts, and blaming Microsoft for forcing them to make those
mistakes.


Mootools' contains be refactored and that's what the good folks at
this thread brought up. MooTools can do a conditional check with a
feature test, create a replacement alternative for their own methods,
and deprecate, for future removal, MooTools' custom
Array.prototype.contains in favor of something that is not
incompatible.


This situation reminds me of the W3C proposal for Event creation to
use `Event` constructor, regardless of Mootools already having defined
a global Event constructor for the web.

That w3c proposal was adopted and implemented, probably with compat
issues, seeing as MooTools has removed their Event for their new
global DOMEvent function, deprecated their global `Event` function,
kept it for backwards compatibility, and then removed it in a
subsequent release.


Their replacement's name "DOMEvent" starts with "DOM" and there is no
guarantee that the w3c won't define a new type of event called
DOMEvent (maybe to describe DOM Mutation). MooEvent is a more
intentional and a better name.

But anyway, MooTools, can with their Array.prototype.contains what
they did with their Event. Maybe with a better name or maybe using
another typeof approach than "rename".


jsfiddle.com
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0115.html
http://www.twitlonger.com/show/bd2994

[Rick Waldron]

On Tue, Sep 30, 2014 at 3:45 PM, Andrea Giammarchi <

Post by Andrea Giammarchi
"the current state of the web" ... with all due respect for that library,
it's been years since I've heard anything about it.

Seconded?arguably MooTools' decline in usership is because of conflicts
such as this.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/865816e4/attachment.html>

[Boris Zbarsky]

Post by Andrea Giammarchi
"the current state of the web" ... with all due respect for that
library, it's been years since I've heard anything about it.

"They have ears, but cannot hear..."

This is a reasonably commonly used library, as libraries go.

-Boris

[Rick Waldron]

Post by Boris Zbarsky

Post by Andrea Giammarchi
"the current state of the web" ... with all due respect for that
library, it's been years since I've heard anything about it.

"They have ears, but cannot hear..."
This is a reasonably commonly used library, as libraries go.

This may be helpful:
http://trends.builtwith.com/javascript/javascript-library

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/873e6892/attachment.html>

[John-David Dalton]

Just a heads up, I've pinged MooTools core to inquire about fast-pathing a
patch release for Array#contains.

- JDD

On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron <waldron.rick at gmail.com>

Post by Rick Waldron

Post by Boris Zbarsky

Post by Andrea Giammarchi
"the current state of the web" ... with all due respect for that
library, it's been years since I've heard anything about it.

"They have ears, but cannot hear..."
This is a reasonably commonly used library, as libraries go.

http://trends.builtwith.com/javascript/javascript-library
Rick
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/3b3f95d7/attachment-0001.html>

[Brendan Eich]

Post by John-David Dalton
Just a heads up, I've pinged MooTools core to inquire about
fast-pathing a patch release for Array#contains.

Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,

/be

[John-David Dalton]

Post by Brendan Eich
Did you ask them to fix their code so it doesn't fail for any name, not

just for 'contains'? Thanks,

I didn't, but will follow up with that.

JDD

Post by Brendan Eich

Post by John-David Dalton
Just a heads up, I've pinged MooTools core to inquire about fast-pathing
a patch release for Array#contains.

Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/7f215760/attachment.html>

[Boris Zbarsky]

Post by Rick Waldron
http://trends.builtwith.com/javascript/javascript-library

Rick, thank you!

This says 1.32% on top 10k sites, 3.05% on top 100k sites, 4.78% on top
million sites, and 6.39% overall.

There's definitely been a recent dip in those numbers, of course. Used
to be even higher.

-Boris

[Jason Orendorff]

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

Well -- true, that would break even more sites.

We're backing out Array#contains() for now. It's disappointing to me
personally -- that was a volunteer contribution. In the long run,
perhaps renaming it is the best course? :-\

-j

[John-David Dalton]

There is no need to change the name.
MooTools has had these issues in the past (they've broke with ES5, ES6, &
ES7 methods).
Array#contains is ES7 so there's time for their patch to release/propagate.

- JDD


On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff <jason.orendorff at gmail.com>

Post by Jason Orendorff

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

Well -- true, that would break even more sites.
We're backing out Array#contains() for now. It's disappointing to me
personally -- that was a volunteer contribution. In the long run,
perhaps renaming it is the best course? :-\
-j
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/e3be0297/attachment.html>

[Rick Waldron]

On Tue, Sep 30, 2014 at 6:04 PM, Jason Orendorff <jason.orendorff at gmail.com>

Post by Jason Orendorff

Post by Michał Wadas
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.

Well -- true, that would break even more sites.
We're backing out Array#contains() for now. It's disappointing to me
personally -- that was a volunteer contribution. In the long run,
perhaps renaming it is the best course? :-\

Unfortunately, it's named to match String.prototype.contains and Domenic
made strong cases in his proposal and presentation for `contains` over
alternatives

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/6af576f3/attachment.html>

[Domenic Denicola]

Welp, nothing to do but add @@unMooToolsables.
________________________________
From: Boris Zbarsky<mailto:bzbarsky at mit.edu>
Sent: ?2014-?09-?30 19:21
To: es-discuss<mailto:es-discuss at mozilla.org>
Subject: Having a non-enumerable Array.prototype.contains may not be web-compatible

See https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it
breaks, for example.

-Boris
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/f5439888/attachment.html>