3 ms·
Adding methods to primitive prototypes should probably have always been considered risky.
by noduerme 4y ago
Adding methods to primitive prototypes should probably have always been considered risky.
- nerdponx 4y agoAlso, is this fixable downstream? I imagine they could have kept a kind of "mixin prototype" object sitting around, and they could enumerate the properties of that object instead of Array, and in doing so attach their custom properties to Array as well as Elements and whatever else. It seems less flaky anyway, compared to relying on this subtle enumerability property.
- eyelidlessness 4y agoThey could of course fix it downstream any number of ways, many more straightforward than adding a layer of indirection to keep monkey patching the built-ins. But that wouldn’t fix sites still running the older code.
- seba_dos1 4y agoThey did fix it downstream. I remember maintaining a JS tool many years ago that was being embedded on client's websites, and before we added a bunch of hacks to make it not break with bad Mootools versions we did manage to convince some non-zero number of clients to fix their sites by updating it.
- noduerme 4y agoIn fairness, one of the nicest things about early JS was the flexibility it offered. It was never meant to be a language for building large libraries and huge applications. Coming from strongly typed languages it was sort of liberating, at a certain point. Now... well, arguably it's okay that it's so loose because it's allowed things like TypeScript to spring up, but you can still just override Array if you feel like it. (Until one day you can't, hah).
- donatj 4y agoHindsight is 2020. There were no major changes to the language between 1997 and 2009. As a developer at the time, JavaScript seemed locked in stone.
- noduerme 4y ago+1 for remembering the CamelCase of the proper name of this garbage language we all write in now ;)