Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement RFC7159 section-4 #26

Open
user454322 opened this issue Apr 25, 2014 · 3 comments
Open

Implement RFC7159 section-4 #26

user454322 opened this issue Apr 25, 2014 · 3 comments
Labels

Comments

@user454322
Copy link

Currently minimal-json allows duplicated names, which is contrary to section 4 of RFC7159, which says: The names within an object SHOULD be unique.

Other parsers throw an exception. JSON in Java for example throws

org.json.JSONException: Duplicate key "status" at 
.... 
@ralfstx
Copy link
Owner

ralfstx commented Apr 25, 2014

The meaning of SHOULD is defined in RFC 2119.
The JSON RFC does not forbid, but only discourage duplicate names, therefore minimal-json leaves the decision to the user. If you want to be sure that you don't add duplicate names to a JsonObject, use set() instead of add(). However, please note that checking for duplicates requires additional hash lookups and does not perform as well as add().

For the parser, we could think about a configuration option. Would this help in your case?

@user454322
Copy link
Author

Hi ralfstx,
I understand the situation and I'm aware of how SHOULD is used in RFCs, therefore I wrote Implement rather than Fix.....and well, since SHOULD is more a recommendation it is technically implemented....my bad.

Leaving the decision to the user makes it more versatile, which might be good.

The spirit of the issue was in the sense of encouraging no duplicates.
The mantra:
 1. Make it work then,
 2. Make it right and then,
 3. Make it fast
is too rooted in my head that I went straight to strict compliance before thinking about performance.

Yes, an option to configure the parser would do the trick

=)

@bernardosulzbach
Copy link
Contributor

Edit: I n00bed and forgot that there is hashing already being done, so except for doing it more it doesn't bring anything new to the table. Performance impact for sure, but not quite as dramatic.

Additionally, programmatically ensuring this is not necessary as JSON is not the problem. If someone wrote the files, they could be unit tested and if they were generated by a system, this system should be fixed.

I am not against an option, just think this would make terrible defaults to a project that tries "not to get in the way".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants