6 ms·
What's wrong with the JSON gem API?
- ezekg 1y agoFirst thing we could do here is rename the JSON.parse :symbolize_names keyword to :symbolize_keys -- always trips me up for some reason.
- athorax 1y agoWhy? JSON is name-value pairs https://www.json.org/json-en.html https://www.json.org/json-en.html
- ezekg 1y agoI guess I'm more thinking about Ruby/Rails conventions, e.g. methods like Hash#symbolize_keys. Mixing the two has always been a smell to me, but maybe you're right.
- caseyohara 1y agoSure, but JSON.parse returns a Hash, which is key-value pairs. The method argument is about the return value, not the input value, so it is more like "Parse this JSON, and symbolize the keys in the resulting Hash before returning it to me". Plus, as mentioned, symbolize_keys is more conventional.
- fuzzy_biscuit 1y agoMaybe it could just be an alias. People do also refer to them as key-value pairs, so that feels reasonable.
- deleted 1y ago[deleted]
- onli 1y agoBreaking the API like that would be extremely hostile and exactly the kind of churn byroot thankfully claimed he does not want to produce. If anything both options could be offered. Don't be disrespectful with developers time.
- jmull 1y agoChanging the default behavior for duplicate keys is unnecessary... and therefore should not be done. IMO, it's nuts to purposely introduce random bugs into the apps of everyone who uses your dependency.
- anitil 1y agoThere was a post here recently about how this sort of behaviour on duplicate keys has actually led to security issues (in the context of Go) [0] [0] https://news.ycombinator.com/item?id=44308953 https://news.ycombinator.com/item?id=44308953
- jmull 1y agoThe issue was triggered by using multiple parsers, with different behaviors. The change of behavior here would prevent the specific problem, but makes the general problem worse. This change creates a new code path that did not exist when all the app code was developed and tested, so there's a decent chance something bad can happen that it's not prepared for.
- anitil 1y agoThe thing that I find surprising about this is that it seems so innocuous. Duplicate keys in an object? Meh just take the first or the last or something, no big deal, I'm sure whatever library I'm using will handle it
- kazinator 1y agoRFC 8259 describes these possibilities, accurately quoted in the article: "Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates." Keeping the first key/value would be a poor idea since it is a behavior not mentioned in the RFC.
- jmull 1y ago
- nurettin 1y agoNot sure what they mean by "json gem", as it comes with ruby and not installed via gem install command. I've always used require 'json/ext' This uses the C extension version and is much faster.
- byroot 1y ago`json` is a "default gem": https://stdgems.org/ https://stdgems.org/ Meaning Ruby ships with that gem pre-installed, but it's still a gem and you can upgrade/downgrade it in your gemfile if you so chose. As for `require "json/ext"` that's outdated knowledge.
- nurettin 1y agoHaha I'd imagine it is outdated. It is from 10+ years ago.
- kazinator 1y agoSince JSON does not specify what happens with duplicate keys, that means it is "unspecified behavior" in language spec speak. Software which prepares JSON with duplicate keys is causing unspecified behavior in downstream processors, and therefore its output can be regarded as broken. If you put out JSON with duplicate keys, you are responsible for whatever consequently blows up in your face or the faces of downstream users.
- xg15 1y agoI don't know any format or application that uses this for legitimate purposes. The most frequent "application" seem to be exploits. As such I don't think the "you're responsible" call would be very helpful. Or rather, you might just as well say "if you send a packet with an overflowing length field, you're responsible for whatever happens downstream".