3 ms·

Mootools already is in conflict with the latest Ecmascript: https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array-from https://mootools.net/core/docs/1.5

Mootools already is in conflict with the latest Ecmascript: https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array-from https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array... No reason to start changing the spec for it now. (And I say that as somebody that works at a company with what is likely one of the largest existing Mootools-based javascript codebases around)

rektide 9y ago
We also dealt with an old MooTools having an incompatible implementation of Function.bind: https://github.com/mootools/mootools-core/issues/2473 https://github.com/mootools/mootools-core/issues/2473 Old MooTools is a huge problem child, and did a really bad job being forwards-compatible with their monkeypatching. They took the half measure of only monkeypatching things when there was no implementation. MooTools eventually got it, and changed their monkeypatching behavior to be more aggressive, such that problem like what we have now wouldn't be a problem. And they kicked out a minor revision to the older libraries, to use this more aggressive monkeypatching behavior (at least for bind. dunno about others?). Agreed fully: there is no reason to change the js spec for now. MooTools made forward-compatibility incredibly difficult for themselves, 8 years ago, but they spent a bunch of effort trying to un-dig themselves out of the hole since. It's unfortunate, but monkeypatching core JS in this manner was really un-advisable and irresponsible.