|
|
|
|
|
by jraph
1225 days ago
|
|
If my programming language changed something so fundamental, I would lose all trust in it even if I don't rely on this particular quirk. PL design is complicated and you pretty much have to keep this kind of quirks forever or at least for a very long time if you want to avoid a painful transition, which can lead to the old language version hanging out forever in the wild because a lot of code is already written in it. You can deprecate the features the quirks affect and introduce new ones to replace them that do not have the quirks, but now you need to support both ways for a very long time until the ecosystem is ready, which may never happen. there's nothing wrong with: switch (typeof v) {
...
case ...:
...
break;
case "undefined":
// handle undefined;
break;
case "object":
if (!v) {
// handle null;
} else if (v instanceof 'Array') {
// handle array;
} else if (...) {
...
} else {
// handle anything else
}
break;
}
that's within spec and an alternative could be more verbose / more difficult to navigate (it's a matter of taste). If you need to handle undefined and null differently, you need to test for it and typeof === "object" is one way. I would probably do it differently, but I can see someone thinking differently and we can't blame them. |
|