6 ms·

Why even? Why don't they fix it?

by abdnafees 4y ago

jwilk 4y ago
Supposedly "because it would break existing code".
tobr 4y ago
> This is a bug and one that unfortunately can’t be fixed, because it would break existing code.
29athrowaway 4y ago
https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
- fsckboy 4y ago
  Linus Torvalds has long had an ironclad rule, "don't break userspace" which sounds like the same thing from the hyrum's law link: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
readthenotes1 4y ago
"The difference between a bug and a feature is longevity." -said by someone last millennium
- bryanrasmussen 4y ago
  that's wrong, but it's been around so long I guess we have to accept it.
  - abdnafees 4y ago
    After asking the question, I looked for an answer and found the is-object npm package. It utilizes a null check to make sure a variable is an object. This utility has 6.6 million weekly downloads. The logic in the isObject function will break because the second condition would then be invalidated. Resulting in a bad day for 6.6 million projects. It took me a while to digest the magnitude. Maybe because I just started as an SWE.
    - andrewmackrodt 4y ago
      If a language change were to update `typeof null` to return `"null"` isObject would not break, the second condition would only be unnecessary. However, other code which may make assertions on null values after checking the value is an object would break.
  - white_dragon88 4y ago
    [dead]
chrismorgan 4y ago
You drastically underestimate how much code depends on typeof null being "object". It’s extremely common in generic/library code. If you changed it to produce, say, "null", vast numbers of websites would completely break. As a simple example, a brief glance at the React and ReactDOM source code, inspecting the first few /typeof.*'object'/ matches, shows that in React, component.setState(null), and in ReactDOM, rendering class-based components with null state (which I’m guessing will be pretty much normal in existing code bases, even if it’s an older pattern now; but I haven’t ever used React seriously), would both throw an exception.
bazoom42 4y ago
Existing code might rely on this behavior, so if it changed some sites will stop working. Even if those sites were updated to the new behavior, browsers are not updated at the same time, so either way there would be a lot of breakage. And some sites will never be updated because they are not actively maintained.

Why even? Why don't they fix it?

jwilk 4y ago

Supposedly "because it would break existing code".

tobr 4y ago

> This is a bug and one that unfortunately can’t be fixed, because it would break existing code.

29athrowaway 4y ago

https://www.hyrumslaw.com/ https://www.hyrumslaw.com/

fsckboy 4y ago
Linus Torvalds has long had an ironclad rule, "don't break userspace" which sounds like the same thing from the hyrum's law link: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

readthenotes1 4y ago

"The difference between a bug and a feature is longevity." -said by someone last millennium

bryanrasmussen 4y ago
that's wrong, but it's been around so long I guess we have to accept it.
- abdnafees 4y ago
  After asking the question, I looked for an answer and found the is-object npm package. It utilizes a null check to make sure a variable is an object. This utility has 6.6 million weekly downloads. The logic in the isObject function will break because the second condition would then be invalidated. Resulting in a bad day for 6.6 million projects. It took me a while to digest the magnitude. Maybe because I just started as an SWE.
  - andrewmackrodt 4y ago
    If a language change were to update `typeof null` to return `"null"` isObject would not break, the second condition would only be unnecessary. However, other code which may make assertions on null values after checking the value is an object would break.
- white_dragon88 4y ago
  [dead]

chrismorgan 4y ago

You drastically underestimate how much code depends on typeof null being "object". It’s extremely common in generic/library code. If you changed it to produce, say, "null", vast numbers of websites would completely break. As a simple example, a brief glance at the React and ReactDOM source code, inspecting the first few /typeof.*'object'/ matches, shows that in React, component.setState(null), and in ReactDOM, rendering class-based components with null state (which I’m guessing will be pretty much normal in existing code bases, even if it’s an older pattern now; but I haven’t ever used React seriously), would both throw an exception.

bazoom42 4y ago

Existing code might rely on this behavior, so if it changed some sites will stop working. Even if those sites were updated to the new behavior, browsers are not updated at the same time, so either way there would be a lot of breakage. And some sites will never be updated because they are not actively maintained.