3 ms·

I would think that you would use a lack of a string to encode a NULL value, e.g.: { "name":"null", "age":"44" } vs { "age":"44" } In the first examp

by bArray 6y ago

I would think that you would use a lack of a string to encode a NULL value, e.g.: { "name":"null", "age":"44" } vs { "age":"44" } In the first example, your get function would return "null" for "name" and in the second example it would return the value of default, which would be implementation specific.

gitgud 6y ago
That demonstrates the exact problem, whatever string you use to represent the null value EG "null" is now a keyword that needs to be enforced. So "null" can no longer be someones username, which will cause weird edge cases...
- bArray 6y ago
  > whatever string you use to represent the null value EG > "null" is now a keyword that needs to be enforced. So in the JSON itself, you literally remove the field. In another comment I make is the point that NULL itself could be considered a proper value, you're just pushing the problem down the line. The library making such a decision for you is what may ultimately trip you up. Instead, you could have something like: string name = jobj.get("name", NULL) So that it does return NULL in this case if a name hasn't been given. But consider an example where you're loading some code into a VM's RAM: int location = toint(jobj.get("address")) NULL in this case is a perfectly valid place to load a program in a VM, or was it that there was an error? Or is it that no address was given in the JSON configuration? Instead, we can specify our own "NULL" value: int location = toint(jobj.get("address", "-1")) So now you're asking to load something before the first position of the VM memory, which indicates an error.
  - gitgud 6y ago
    I think we're in agreement, originally it was suggested to use a "null" string, instead of NULL as a value, which is what I said might cause weird error cases. > So in the JSON itself, you literally remove the field. That's a good point, but in some cases having a `null` is an easier option, as you only need to determine if the value is valid, not if it exists AND is valid (but I suppose you could say it's always valid if it exists... that's if you trust the endpoint to provide valid values though). > But consider an example where you're loading some code into a VM's RAM Allocating memory locations from dynamically created JSON values is bound to lead to many different errors... I guess my main point is that JSON is inherently untyped and suited for messy data or user input. This messiness makes data validation on the consumer of the JSON necessary, which means the consumer has to check if the value is valid before using it. In most cases `null` is considered invalid but if the field isn't there, then it could be an error in the JSON provider.

by bArray 6y ago

gitgud 6y ago

That demonstrates the exact problem, whatever string you use to represent the null value EG "null" is now a keyword that needs to be enforced. So "null" can no longer be someones username, which will cause weird edge cases...

bArray 6y ago
> whatever string you use to represent the null value EG > "null" is now a keyword that needs to be enforced. So in the JSON itself, you literally remove the field. In another comment I make is the point that NULL itself could be considered a proper value, you're just pushing the problem down the line. The library making such a decision for you is what may ultimately trip you up. Instead, you could have something like: string name = jobj.get("name", NULL) So that it does return NULL in this case if a name hasn't been given. But consider an example where you're loading some code into a VM's RAM: int location = toint(jobj.get("address")) NULL in this case is a perfectly valid place to load a program in a VM, or was it that there was an error? Or is it that no address was given in the JSON configuration? Instead, we can specify our own "NULL" value: int location = toint(jobj.get("address", "-1")) So now you're asking to load something before the first position of the VM memory, which indicates an error.
- gitgud 6y ago
  I think we're in agreement, originally it was suggested to use a "null" string, instead of NULL as a value, which is what I said might cause weird error cases. > So in the JSON itself, you literally remove the field. That's a good point, but in some cases having a `null` is an easier option, as you only need to determine if the value is valid, not if it exists AND is valid (but I suppose you could say it's always valid if it exists... that's if you trust the endpoint to provide valid values though). > But consider an example where you're loading some code into a VM's RAM Allocating memory locations from dynamically created JSON values is bound to lead to many different errors... I guess my main point is that JSON is inherently untyped and suited for messy data or user input. This messiness makes data validation on the consumer of the JSON necessary, which means the consumer has to check if the value is valid before using it. In most cases `null` is considered invalid but if the field isn't there, then it could be an error in the JSON provider.