Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I’m trying to understand the JSON merge patch RFC the post refers to.

How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing?

Edit: oh, it’s in the RFC. I just missed it:

“ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explicit null values. The merge patch format is not appropriate for all JSON syntaxes.”

So it remains simple without any sort of DSL needed to describe changes like “remove this key” by somewhat hijacking ‘null’. Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.

View on HN

>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.

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.

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” ;)

> and therefore the value is null

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.

Until you try JSON.stringify({a: null, b: undefined})

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).)

[1] https://stackoverflow.com/q/61420580

Reply on news.ycombinator.com