Serialization inconsistent when dash is used

[mck-]

JSON> "{\"hello-world\" : 888}"
"{\"hello-world\" : 888}"
JSON> (decode-json-from-string *)
((:HELLO-WORLD . 888))
JSON> (encode-json-to-string *)
"{\"helloWorld\":888}"

"hello-world" becomes "helloWorld" after serialization through CL-JSON

[mck-]

Sorry, I just noticed this in the documentation: The functions are not strictly inverse.

Any reason why not?

[rpgoldman]

There's some freedom here in how to translate strings from what JavaScript offers. I'd argue that there are three different alternatives:

1. Strings. "hello-world" => "hello-world"
2. Lisp symbols preserving original case. I.e., |hello-world| here. Some would find this awkward -- it can be cumbersome to work with literals for case-sensitive lisp symbols.
3. Lisp symbols "rectified" to take into account the fact that CL coders tend to treat symbols as case-insensitive. Doing this, one typically wants to do something to preserve the information in theCamelCase. A common trick is to replace the camel-case boundaries with hyphens, so "helloWorld" becomes HELLO-WORLD. Unfortunately, as your example points out, "hello-world" would ''also'' become HELLO-WORLD. I see two further alternatives here:
4. Ignore the problem. Non-lispers tend to use camel case or underscores where lispers use hyphens and tend to avoid embedded hyphens. In this alternative, you lose if there are embedded hyphens in the string, but you figure it won't happen. Alternatively, you could trap embedded hyphens and raise an exception.
5. Resolve the ambiguity. One solution would be "hello-world" becoming HELLO--WORLD.
   Another problem with rectification is that "helloWorld" and "HelloWorld" both map to HELLO-WORLD. I guess one could map the latter to -HELLO-WORLD.

Because of this ambiguity, it will be best for programmers to explicitly specify the translation method (I have forgotten the details of the code, but I thought there was a way to specify translation methods explicitly). However, it would also be good for the default method to do something reasonable that at least mostly preserves round-tripping.

[mck-]

Thanks for the treatise :) For now I'll probably resort to i. to avoid trouble.. ii. would be ideal (although the -- solution is gonna collide with the "_".. so another symbol would be needed)

[aslakg]

I noticed the round-trip problem as well, caused me some headache to pin down:
(funcall cl-json:lisp-identifier-name-to-json (funcall cl-json:json-identifier-name-to-lisp "kqgbldkt2Hn7sne"))
"kqgbldkt2Hn7Sne"
The s changes to uppercase after the number 7. It's not ideal default behaviour. I am aware there are workarounds however.