101–110 of 163 posts
TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
TOML sucks in so many ways. It is about 8x better than YAML, INI, or JSON though. It is good enough that I can ignore its flaws.
JSON should be banned for configuration, if only for the fact it doesn’t support comments.
All the benefits of JSON, no new syntax to learn, easy to fit in place in new or existing systems.
I honestly find TOML harder to read and more complicated to use than YAML. I tried to look into it but frankly I still haven't found a use case where it made more sense to use TOML.
Earlier quoted context omitted.
> GUIDs, IP Addresses, and byte arrays. In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000 As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but…
It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…
Earlier quoted context omitted.
This is a table. Let's see it do a tree. (And not an adjacency matrix. That's cheating.)
A tree is a graph without cycles. A graph is a relational structure E(a,b) which can easily be stored in tables. This is why relational databases like SQL store tables. So there's nothing exceptional about storing graphs, and adjacency lists or matrices are all fine. To connect with the other threads, SQLite would be probably the best candidate proposed here to store a tree.
TOML does a much better job than CSV.
YAML and TOML wouldn't have been necessary if JSON had been slightly more expressive. If JSON had * comments * bareword (not double quoted) object key names it'd be a much more suitable configuration file format for everything, and I don't think we'd see the motivation to make things like TOML and YAML.
Yep. And trailing commas,
Earlier quoted context omitted.
> GUIDs, IP Addresses, and byte arrays. In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000 As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but…
It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…
Is this really an issue when loading a field from a config file? If it was something happening 1m times per second then maybe I could see your point.