Re: Having a non-enumerable Array.prototype.contains may not beweb-compatible
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 andrea.giammar...@gmail.com wrote: 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.dal...@gmail.com Sent: 01/10/2014 00:54 To: Jason Orendorff jason.orendo...@gmail.com Cc: Andrea Giammarchi andrea.giammar...@gmail.com; es-discuss es-discuss@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.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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. 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. 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@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: Having a non-enumerable Array.prototype.contains may not beweb-compatible
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? On 10/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote: FYI: from a MooTools core developer: 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 -- Garrett @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Having a non-enumerable Array.prototype.contains may not beweb-compatible
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.dal...@gmail.com Sent: 01/10/2014 00:54 To: Jason Orendorff jason.orendo...@gmail.com Cc: Andrea Giammarchi andrea.giammar...@gmail.com; es-discuss es-discuss@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.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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. 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. 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
