Hacker News Reader

Comment by varikin | Hacker News Reader

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?

View on HN

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

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

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

Granted, hosay123's comment [982] is much more valid, though.

[982] https://news.ycombinator.com/item?id=6147084

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

About as defined as anything else in JSON, eg. the range of integers.

Actually, duplicate keys is very specifically recommended against in the RFC, and left entirely unspecified.

Reply on news.ycombinator.com