3 ms·

I'd love to see the counter-evidence! Works on every browser, every server-side JS engine of note. Edit: I believe a number of these non-determinism did get fo

I'd love to see the counter-evidence! Works on every browser, every server-side JS engine of note. Edit: I believe a number of these non-determinism did get formally resolved in EcmaScript itself, which is yes, not the same, but is an active, alive, & notable specification with some bearing.

vsnf 4y ago
Go will serialize keys to maps in random order, meaning that unless you take special and extraordinary precautions while serializing your json structs, you will get keys that will not be where you expect them to be.
- rektide 4y ago
  This does not appear to be true[1][2]. [1] https://github.com/golang/go/issues/24415 https://github.com/golang/go/issues/24415 [2] https://go.dev/play/p/nXLs0hd8Uj3 https://go.dev/play/p/nXLs0hd8Uj3
tikhonj 4y ago
First thing I tried was the Haskell Aeson library which keeps the first value of the key: λ> decode f :: Maybe Value Just (Object (fromList [("this_article",String "// would be better")])) There's a more flexible jsonWith function that lets you control how duplicates (and, for that matter, field order) is handled, but it's not the default. The handful of other tools I spot-checked all keep the last pair, so it seems like almost but not quite standard behavior. I was curious about other programs and, searching around, found a discussion[1] about standardizing the behavior to "either reject objects with duplicate keys or keep the last value"; however, from a quick scan, that wasn't added to any of the standards documents I found. Apart from the standard I linked earlier there are a couple of JSON RFCs[2][3], but they basically say "different systems do different things and if you depend on the behavior, your JSON won't be universally interoperable" > When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. 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. > JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences. If anything, the fact that it is almost but not quite standard behavior probably makes it worse—you can rely on it for quite a while until it unexpectedly breaks and the figuring out why it broke will be a real headache. [1]: https://esdiscuss.org/topic/json-duplicate-keys https://esdiscuss.org/topic/json-duplicate-keys [2]: https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159 [3]: https://datatracker.ietf.org/doc/html/rfc8259 https://datatracker.ietf.org/doc/html/rfc8259
- rektide 4y ago
  I found the EcmaScript specification[1]: > In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten. So in JavaScript, it indeed will always work. But yes, other languages & libraries are under no obligation to follow this behavior. As you clearly show, the JSON spec itself highlights it's displeasure with & the unpredictability of duplicate keys, while also noting the two prevailing behaviors: accept last, or fail. [1] https://262.ecma-international.org/12.0/#sec-internalizejsonproperty https://262.ecma-international.org/12.0/#sec-internalizejson...
  - dmitriid 4y ago
    There are at least seven different JSON specifications. And no, the ecmascript one isn't the "canonical" one. More details if you ever wanted them, here: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
    - rektide 4y ago
      Please stop trolling my threads to piss on my statememts. You're being awful to me? I dont think I implied at all that kson was canonical nor absolute. I think I agreed thay it was unclear .
      - dmitriid 4y ago
        No. I'm not being awful. I'm being objective.
        rektide 4y ago
        You were cruel & wrong & malicious this time. Again. Added nothing I nor who I was discussing with hadn't already actively agreed to already. Meanly.

vsnf 4y ago

Go will serialize keys to maps in random order, meaning that unless you take special and extraordinary precautions while serializing your json structs, you will get keys that will not be where you expect them to be.

rektide 4y ago
This does not appear to be true[1][2]. [1] https://github.com/golang/go/issues/24415 https://github.com/golang/go/issues/24415 [2] https://go.dev/play/p/nXLs0hd8Uj3 https://go.dev/play/p/nXLs0hd8Uj3

tikhonj 4y ago

First thing I tried was the Haskell Aeson library which keeps the first value of the key: λ> decode f :: Maybe Value Just (Object (fromList [("this_article",String "// would be better")])) There's a more flexible jsonWith function that lets you control how duplicates (and, for that matter, field order) is handled, but it's not the default. The handful of other tools I spot-checked all keep the last pair, so it seems like almost but not quite standard behavior. I was curious about other programs and, searching around, found a discussion[1] about standardizing the behavior to "either reject objects with duplicate keys or keep the last value"; however, from a quick scan, that wasn't added to any of the standards documents I found. Apart from the standard I linked earlier there are a couple of JSON RFCs[2][3], but they basically say "different systems do different things and if you depend on the behavior, your JSON won't be universally interoperable" > When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. 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. > JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences. If anything, the fact that it is almost but not quite standard behavior probably makes it worse—you can rely on it for quite a while until it unexpectedly breaks and the figuring out why it broke will be a real headache. [1]: https://esdiscuss.org/topic/json-duplicate-keys https://esdiscuss.org/topic/json-duplicate-keys [2]: https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159 [3]: https://datatracker.ietf.org/doc/html/rfc8259 https://datatracker.ietf.org/doc/html/rfc8259

rektide 4y ago
I found the EcmaScript specification[1]: > In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten. So in JavaScript, it indeed will always work. But yes, other languages & libraries are under no obligation to follow this behavior. As you clearly show, the JSON spec itself highlights it's displeasure with & the unpredictability of duplicate keys, while also noting the two prevailing behaviors: accept last, or fail. [1] https://262.ecma-international.org/12.0/#sec-internalizejsonproperty https://262.ecma-international.org/12.0/#sec-internalizejson...
- dmitriid 4y ago
  There are at least seven different JSON specifications. And no, the ecmascript one isn't the "canonical" one. More details if you ever wanted them, here: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
  - rektide 4y ago
    Please stop trolling my threads to piss on my statememts. You're being awful to me? I dont think I implied at all that kson was canonical nor absolute. I think I agreed thay it was unclear .
    - dmitriid 4y ago
      No. I'm not being awful. I'm being objective.
      - rektide 4y ago
        You were cruel & wrong & malicious this time. Again. Added nothing I nor who I was discussing with hadn't already actively agreed to already. Meanly.