With regards to duplicate key names, some libraries allow for the same key to be parsed resulting in multiple child nodes of the same name. Others throw an exception when parsing an object with a duplicate key name.
The correct way to handle duplicate keys is to overwrite the existing key when a duplicate is encountered. My library does have Save/Load To/From /File/Stream. Please see the articles I posted. They are listed there. Unicode support exists in both allowing unicode to be in the JSON, and escape inotpced e.g. \u00ae becomes ® a two byte utf8 encoding char when parsed by my parser. It also saves/load that utf8 encoding to steams or files. Regarding indentation and formatted, I support two options as noted in my original article. The AsJson property create spaceless compact JSON suitable for network traffic, while the Vale property allows for friendly human readable formatting and indentation. Currently the friendly indentation is fixed and I doesn't see a reason use case reason to allow for custom indentation beyond what I already provide. And finally regarding the unicode failure of FPJson, I am parsing a small bit of JSON ... { "name": "Joe\u00aeSchmoe"} And compare it to the value of 'name' to the string constant 'Joe®Schmoe' in pascal code. If fails the first iteration, but if I run it a second time it works, so there is something amiss. And finally with regards to plugins and extensiblity, that's great to have, but I am just trying to write something that handles the JSON spec and only that. If I want something to stream a form layout or settings to JSON it would be a separate wholly independent library that depends ona parser, but isn't part of the parser library.
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus