4 ms·
The other way SAN isn't json compatible is lack of null. As for heterogenous list types, great reason to have them is when your list is logically the same type
by epage 8y ago
The other way SAN isn't json compatible is lack of null.
As for heterogenous list types, great reason to have them is when your list is logically the same type but physically isn't.
In some formats like Cargo.toml, the following are equivelant:
dep="1.8"
dep={version="1.8"}
This allows a short-hand for the common case. Being able to do this in lists would improve the file formats I've been making.
- chme 8y agoI used lists to build my own include concept in yaml like so: includes: - relative-include-file.yml - url: git://stuff.git file: git-included-file.yml Not possible here. (Of course I would need to change the string to a map as well, but that is just clunky to write all the time.)
- z0mbie42 8y agoThat's the point, we didn't ever find a good reason to use heterogeneous lists. They can all be replaced by maps which may seems more verbose but carry in fact far more information and clear
- chme 8y agoFor me a configuration file should be easy to write and read while not taking so much care about the data types. So for me you get a shoe if you reverse your argument. Type limitations aren't improving write or readability IMO and just make it harder, because you have to think about using the right type. Application specific schema checkers should take care of the checking the type.