5 ms·

Why are pointers strings? They are really multi-indexes, so why are they not arrays of strings (for hashes/"objects") and numbers (for arrays)? This would hav

Why are pointers strings? They are really multi-indexes, so why are they not arrays of strings (for hashes/"objects") and numbers (for arrays)? This would have avoided the need for escaping and for string operations in general, which complicate the whole thing.

formerly_proven 4y ago
Quite honestly, I've yet to see an RFC with JSON in the title that isn't a disaster in one way or another.
laurent123456 4y ago
I guess it's more user friendly to have the path as a string, except of course most of these patches will be machine generated and processed, so the user friendliness is a bit pointless.
throwawaymaths 4y ago
Shorter encoding. Count the bytes: ["foo","bar",1,"baz","quux"] Vs "/foo/bar/1/baz/quux" It's also less parsing, and for many systems a less wieldy/less errorprone entity to pass around your runtime. You unpack it at the time you need to dereference the JSON pointer.
jitl 4y ago
I don’t get this either, the byte savings are trivial and escaping/unescaping logic adds needless encoding complexity to a concept that otherwise does not need string encoders! At Notion, we use Array<string | number> as you suggest.
anentropic 4y ago
partly probably just because JSON Pointer spec already exists it's used in OpenAPI specs apparently the goal was something that could be transferred in string contexts like a URI fragment, as well as JSON https://datatracker.ietf.org/doc/html/rfc6901#section-1 https://datatracker.ietf.org/doc/html/rfc6901#section-1
simiones 4y ago
I think it's natural to do it this way, since it's common for a REST API to also support GETs inside objects using URLs. That is, `GET /` can return `{"top": [{"key": "value"}]}`, while `GET /top/1` can return `{"key": "value"}`. So, reusing the same syntax to refer to fields comes very naturally if you already have this support.

formerly_proven 4y ago

Quite honestly, I've yet to see an RFC with JSON in the title that isn't a disaster in one way or another.

laurent123456 4y ago

I guess it's more user friendly to have the path as a string, except of course most of these patches will be machine generated and processed, so the user friendliness is a bit pointless.

throwawaymaths 4y ago

Shorter encoding. Count the bytes: ["foo","bar",1,"baz","quux"] Vs "/foo/bar/1/baz/quux" It's also less parsing, and for many systems a less wieldy/less errorprone entity to pass around your runtime. You unpack it at the time you need to dereference the JSON pointer.

jitl 4y ago

I don’t get this either, the byte savings are trivial and escaping/unescaping logic adds needless encoding complexity to a concept that otherwise does not need string encoders! At Notion, we use Array<string | number> as you suggest.

anentropic 4y ago

partly probably just because JSON Pointer spec already exists it's used in OpenAPI specs apparently the goal was something that could be transferred in string contexts like a URI fragment, as well as JSON https://datatracker.ietf.org/doc/html/rfc6901#section-1 https://datatracker.ietf.org/doc/html/rfc6901#section-1

simiones 4y ago

I think it's natural to do it this way, since it's common for a REST API to also support GETs inside objects using URLs. That is, `GET /` can return `{"top": [{"key": "value"}]}`, while `GET /top/1` can return `{"key": "value"}`. So, reusing the same syntax to refer to fields comes very naturally if you already have this support.