4 ms·

As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list

As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point. My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situations where you want to represent a JSON document as a string. (Trivial example, as an embedding in an HTTP response object).

Izkata 4y ago
> The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map<string, JsonValue> is pretty close to how it's used in Java and other languages that don't have native types that match its structure (like javascript and python do). > (Trivial example, as an embedding in an HTTP response object) This isn't json, it's what you get when you stringify/dumps/convert the json into a different datatype. When you need to be specific it's often called a "json string".
- jstimpfle 4y ago
  JSON is a data-interchange format, i.e. a specification how to serialize and deserialize a domain of values. So Map<string, JsonValue> "isn't JSON" either. JSON isn't a solved problem, it's a solution to a problem (and often used as a non-solution to a non-problem). But none of that was my point.
- afiori 4y ago
  JSON is often interpreted as dictionary but is serialized as key-value pairs, for JSON itself this is not a big problem as everybody agrees not to produce JSON documents like {"a":1,"b":2,"a":3} so most people do not care about how their parser reads them. In cases like URL queries or HTTP headers it is not such a clear cut. There it is common both to use duplicated keys and to use JSON-like dictionaries to read them. Personally I never had bugs due to this: PHP does the "right" thing with duplicated keys and I never encountered it in node, but it bugs me that we use this kind of lossy[0] representations. [0] in JS in particular the object are not really adequate to be used as dictionaries, inheritance and predefined keys aside there are also special magical attributes that behave in special ways Object.getPrototypeOf(Object.assign({}, JSON.parse('{"__proto__":null}')))===null;

Izkata 4y ago

> The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map<string, JsonValue> is pretty close to how it's used in Java and other languages that don't have native types that match its structure (like javascript and python do). > (Trivial example, as an embedding in an HTTP response object) This isn't json, it's what you get when you stringify/dumps/convert the json into a different datatype. When you need to be specific it's often called a "json string".

jstimpfle 4y ago
JSON is a data-interchange format, i.e. a specification how to serialize and deserialize a domain of values. So Map<string, JsonValue> "isn't JSON" either. JSON isn't a solved problem, it's a solution to a problem (and often used as a non-solution to a non-problem). But none of that was my point.
afiori 4y ago
JSON is often interpreted as dictionary but is serialized as key-value pairs, for JSON itself this is not a big problem as everybody agrees not to produce JSON documents like {"a":1,"b":2,"a":3} so most people do not care about how their parser reads them. In cases like URL queries or HTTP headers it is not such a clear cut. There it is common both to use duplicated keys and to use JSON-like dictionaries to read them. Personally I never had bugs due to this: PHP does the "right" thing with duplicated keys and I never encountered it in node, but it bugs me that we use this kind of lossy[0] representations. [0] in JS in particular the object are not really adequate to be used as dictionaries, inheritance and predefined keys aside there are also special magical attributes that behave in special ways Object.getPrototypeOf(Object.assign({}, JSON.parse('{"__proto__":null}')))===null;