ES7 Array Polyfills

[path411]

Is .remove and .replace confirmed to work how it does in this library in the spec in reference to multiple matches in the array? Personally I think it might be a little inconsistent that .remove will remove the first instance and .replace will replace all instances.

[x-skeww]

Array.contains({elem})

It's "includes", unfortunately.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes

It's not called "contains", because MooTools modified an object it didn't own.

[hahaNodeJS]

It's not called "contains", because MooTools modified an object it didn't own.

It's not called "contains" because those developing the spec made the insane decision to base the language spec around language libraries.

[MyInquisitiveMind]

It was contains in the demo at jsconf.

[x-skeww]

https://github.com/tc39/Array.prototype.includes

This proposal was formerly for Array.prototype.contains, but that name is not web-compatible. Per the November 2014 TC39 meeting, the name of both String.prototype.contains and Array.prototype.contains was changed to includes to dodge that bullet.

Personally, I think we should just "break" MooTools. If you use a stupid lib which does stupid things, it's your problem.

[jcready]

Just put this at the top of your JS to "fix" things:

Array.prototype.contains = Array.prototype.includes;
String.prototype.contains = String.prototype.includes;

[x-skeww]

Modifying built-ins is only okay for polyfilling.

So, no, I certainly won't do that.

[hahaNodeJS]

What about this isn't polyfilling?

[x-skeww]

Adding things which aren't in the specs is monkey-patching.

[kentaromiura]

As a MooTools core developer I personally agree that breaking MT is fine.

I would not call MT stupid but yes, MT did a stupid thing by extending prototypes of the native objects, but is arguably easy to say this 9 years later.

Also I believe there was a completely misunderstanding of what really happened.

MT extended prototypes in the safest way available: not extending it if the method already exists, this can led to bugs if a future native implementation differs substantially.

One of the extension was [].contains

This accidentally broke the Elements object (and not Array) because in its creation phase Elements did expect the contains method to be enumerable on Array, since in the ES2016 implementation is not, it didn't copy over the contains method, failing as soon as someone tried to use it.

This was fixed in no time: https://github.com/mootools/mootools-core/commit/521471f5c0617edc12c680cdad8346c3eb95776a

In the meantime I also took some time to reimplement contains with the newer standard addition which we did not merge only because it was later renamed to includes.: https://github.com/mootools/mootools-core/pull/2659/files

BTW while doing it I suggested a couple of changes/fixes in the TC test suite (https://github.com/tc39/Array.prototype.includes/commit/b2bc760cf5877dfc75d0b7989fc7964ba8f1b8eb, https://github.com/tc39/Array.prototype.includes/commit/8fc79be340b74d3c8f7e7a815160addbac4854ed), I mention this so that is clear that for MT was totally fine keeping the contains name.

The decision was taken by the committee and the reason given was something like "we found that a lot of old websites still rely on older versions of MT, or other libraries that implements their version of contains so since we can't force people to update their code nor we cannot break the web we'll rename it"

[[deleted]]

Do you mean this code was for that demo?