4 ms·
I'm of the opinion that any types other than strings in JSON is a mistake - any parsing assumptions will _never_ be future sufficient. It should be the user of
by bArray 6y ago
I'm of the opinion that any types other than strings in JSON is a mistake - any parsing assumptions will _never_ be future sufficient. It should be the user of the library's responsibility to implement their own string->type conversions.
- skrebbel 6y agoEven null and booleans?
- shawnz 6y agoI think null at least is a great example of their point since many applications might not want a "null" type. Although I am not sure I would go as far as to drop booleans. As for numeric types, that's a complicated issue, I think they should be supported for pragmatic reasons even though it's impossible to come up with a numeric type that satisfies everyone.
- bArray 6y agoI think booleans might even be the most problematic, as it's _really_ implementation specific. In C for example you might expect 1 == TRUE, but in other languages this is not the case. The real problems come in when you handle unexpected cases - and there's no real answer as to whether you return true, false or an error. Personally I think the responsibility should be thrown back at the coder. E.g. I will sometimes do: if(!(jobj.get("key", "true").contains("f")))fun(); Where "true" is considered safe and default. Generally you need to make some effort to switch it off by making sure an "f" exists somewhere, but either case is fine. Imagine for example that the value "true" turns on something potentially dangerous, you might want to guard against accidentally switching it on with: if(jobj.get("key", "false").equals("true"))fun(); So you for sure have to make sure the string is "true" to switch it on, nothing else.
- bArray 6y ago> Even null and booleans? I would say so yes. Pick null for example, depending on your language of choice, you might choose to utilize: "null", "NULL", "", "undefined", "\0", etc. The same with booleans, are we speaking "true", "True", "TRUE", "1", "0xFFFFFFFF", or anything that isn't a false is true, etc. Really how you want to handle these situations is entirely up to you. Personally I prefer some functions like: string s = jobj.get(key, default) The default value being used if a valid string could not be found. Your default could of course be null or equivalent (handle the error), or it could be some known safe value (the show must go on).
- ars 6y ago> Pick null for example, depending on your language of choice, you might choose to utilize: "null", "NULL", "", "undefined", "\0", etc. That's an argument against your position not for. By having a type "null", there's no issue of interoperability between languages who write null in different ways.
- bArray 6y agoTo me the "NULL" of JSON is really the lack of a value. I think having a NULL value could introduce problems. For example: Did you set `{"address":null}` or did you set `{"address":0x00000000}`? It's important to know the difference, do you need to throw an error or warning? If your NULL value maps to something that is also valid input, how are you supposed to know how to handle the case? If you removed the "address" key on the other hand, you can simply do some exists() functions check. I think putting types into the JSON spec only serves to create confusion. I think the JSON libraries should offer common helper functions for doing these conversions (e.g. string -> int), but ultimately it's the responsibility of the coder.
- underwater 6y agoIf you encode everything in strings then you have to have a shared schema between producer and consumer and redundant isset fields. Otherwise you can't be sure to interpret values. Is "name": "Null" a missing value or someone's surname. Is "country": "NO" a falsey value or Norway?