5 ms·
This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value
by varikin 13y ago
This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?
- dak1 13y agoSince the order of an object's keys is not guaranteed, it seems like even if a parser respected the last-defined rule, you could still potentially end up with the wrong field last.
- deleted 13y ago[deleted]
- ygra 13y agoNot really defined, but since an object is defined as an unordered collection of key/value pairs, a conforming parser could probably shuffle the pairs before parsing them.
- treerex 13y agoI suppose it could, but the point of the object being defined as an unordered collection is because the most straight-forward way of implementing this is through a hash table, where the order of the keys cannot be guaranteed without additional work. I'm sure they didn't consider a parser randomly permuting the lexical order of the pairs as something a sane person would do.
- ygra 13y agoGranted, hosay123's comment [982] is much more valid, though. [982] https://news.ycombinator.com/item?id=6147084 https://news.ycombinator.com/item?id=6147084
- IanCal 13y agoWell it could perfectly sensibly do this: if not key in hash: hash[key] = value That's a sensible approach, valid as per the spec. > I'm sure they didn't consider a parser randomly permuting the lexical order of the pairs as something a sane person would do. It could sort the keys, in which case the order is no longer guaranteed (again this doesn't seem insane). The proposal is to rely on undefined behaviour for comments. I'm amazed we're still talking about this.
- rwmj 13y agoAbout as defined as anything else in JSON, eg. the range of integers.
- masklinn 13y agoActually, duplicate keys is very specifically recommended against in the RFC, and left entirely unspecified.