3 ms·

… could’ve at least disallowed for one of the most batshit crazy aspects of JSON, the legal but undefined behaviour of duplicate keys in objects. > An object w

by q3k 5y ago

… could’ve at least disallowed for one of the most batshit crazy aspects of JSON, the legal but undefined behaviour of duplicate keys in objects. > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable.

esnard 5y ago
It would lose its "backwards compatible" property though.
- lifthrasiir 5y ago
  This can be solved if you base JSON5 on I-JSON (RFC 7493) instead of JSON (RFC 8259). Many (but not all) JSON implementations actually expect I-JSON, at least for object keys.
- dane-pgp 5y ago
  Having a defined, predictable behaviour in JSON5 doesn't seem like it would break backwards compatibility with JSON's undefined, unpredictable behaviour. I don't think someone with an existing JSON document would complain that a JSON5 parser behaved "too predictably" when interpreting their document.
  - brundolf 5y ago
    It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.
    - dane-pgp 5y ago
      So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."
      - brundolf 5y ago
        This attitude willfully ignores real-world constraints. There are plenty of "shoulds", but at the end of the day, changing behavior is changing behavior. Maybe it's worth it, maybe it isn't. But it's never free.
cryptonector 5y ago
Those are fightin' words you know... I've seen some of the endless flamewars about removing that. The problem is ultimately that you kinda can't remove duplicate keys. You can only explain the ways in which handling them varies. I'm glossing over a lot of stuff though and I'll understand your skepticism.

by q3k 5y ago

esnard 5y ago

It would lose its "backwards compatible" property though.

lifthrasiir 5y ago
This can be solved if you base JSON5 on I-JSON (RFC 7493) instead of JSON (RFC 8259). Many (but not all) JSON implementations actually expect I-JSON, at least for object keys.
dane-pgp 5y ago
Having a defined, predictable behaviour in JSON5 doesn't seem like it would break backwards compatibility with JSON's undefined, unpredictable behaviour. I don't think someone with an existing JSON document would complain that a JSON5 parser behaved "too predictably" when interpreting their document.
- brundolf 5y ago
  It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.
  - dane-pgp 5y ago
    So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."
    - brundolf 5y ago
      This attitude willfully ignores real-world constraints. There are plenty of "shoulds", but at the end of the day, changing behavior is changing behavior. Maybe it's worth it, maybe it isn't. But it's never free.

cryptonector 5y ago

Those are fightin' words you know... I've seen some of the endless flamewars about removing that. The problem is ultimately that you kinda can't remove duplicate keys. You can only explain the ways in which handling them varies. I'm glossing over a lot of stuff though and I'll understand your skepticism.