>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
In some cases true. In my case, I don’t allow keys to come and go: they’re always defined. The JSON schemas validate that. But I use null to describe “there is no value for this key yet” (such as dateDeleted). If I were to implement merge patching, maybe by turning on a flag in my given framework, I’d be in for a surprise about what my null values now mean (that the schema catches immediately and never makes it to prod.)
I’m of two minds. I like how simple it is. But they’ve basically ignored a problem because the solution is complex. And so they’re hijacking a data type in a rather perilous way. Maybe they should have specified a magic string value that is treated as “DELETEME” ;)
That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
Gosh. If “undefined” was part of JSON and it was always 100% semantically identical to “this key doesn’t exist on this object” then I could see myself not hating “undefined”. Unfortunately “undefined” in javascript isn’t even the same as “key doesn’t exist.” It’s just another null type.
Which in turn led V8 to invent TheHole[1], a true unset value, as an implementation detail (unavailable to the user).
Honestly, it seems to me that pre-strict-mode JavaScript actually made a fair attempt at making "undefined" a genuine missing value, except that then implied semantics people disliked, like an undefined variable reference having the value of "undefined" instead of being an error. Lua seems mostly OK having an actual nil, though. (There is admittedly some gnarliness, like a vararg function f being able to distinguish f(1,2,nil) from f(1,2).)
I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.
Right, but my main point here is that if your business logic cares about the distinction, you've created a pointless footgun 99% of the time. If you care because you're worried about formatting issues or string corruption, there are a million better ways to check for those.
To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.