4 ms·
While I agree with your general point ("don't break existing APIs"), I disagree with the current approach (I made a specific comment down there). This would NO
by alanfranzoni 8y ago
While I agree with your general point ("don't break existing APIs"), I disagree with the current approach (I made a specific comment down there).
This would NOT have been a breaking language change; the problem was introduced by a library that overrides a BUILTIN PROTOTYPE. Let's hope no library (or userspace code) overrides the "flat" method as well.
Overriding other people's code, especially core languages parts, is inherently risky from an API stability POV. I don't think all users appreciate such risk.
- kd5bjo 8y agoIf you aren't supposed to override the builtins, why does the language allow it at all? Lots of others don't. The answer, of course, is that we didn't realize it was a bad practice at the time and there's a bunch of legacy code around that uses the misfeature. If the JS community doesn't want to support this paradigm anymore, they should do it explicitly and lock the builtins from being changed in user code. Until then, we should treat it like the valid approach it is.
- alanfranzoni 8y agoIf you prevent builtin overrides now, you'll break the API. We should start discouraging it, as Mozilla does in its MDN. Maybe some deprecationwarning is a good point to start with. By the way, Javascript was designed in two weeks. I doubt a lot of thought went into such specific details. And the fact that the language doesn't prevent it doesn't make it a good idea - otherwise I'd claim that UB in C is a good idea.
- kd5bjo 8y agoI never claimed it was a good feature, only that the language maintainers should either support code written with it or formally remove it instead of letting it rot with subtle breakage.