81–90 of 163 posts
I've always had a soft spot for the classic .INI style configuration. Modding command and conquer through "rules.ini" was always an adventure.
Earlier quoted context omitted.
I recently wrote a TOML parser in Idris2. It's a cool language, but has some quirks. For me, it's that it's just a simple KV store with some sugar (that's nice!) but it also means that a lot of information is lost forever in parsing. For example, these two documents are strictly identical: [info] name = { first="bob", last="jones" } and info.name.first="bob" info.name.first="jones" This can be seen as a positive (it'…
Can you expand on the negatives? I don't think I understand what you mean.
As a comparison, there's not much choice when serializing to JSON - the only variation is around whitespace. When serializing TOML you need more insight to decide what's the best representation for a human. A contributing factor to this issue is that TOML is mostly used for configuration files, so it often matters that the output is readable.
Earlier quoted context omitted.
> the standard library is where packages go to die I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.
Python now includes pip itself in the standard library (which is a spectacularly poor decision IMO).
Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss. I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating. YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration. JSON is too strict/simple.…
JSON is too strict/simple This is why I like JSON! I have seen the horrors of XSLT and I’m never going back.
In TOML (or YAML) it's just as easy as prepending it with # at the beginning of the line.
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.
I was constantly reading/writing config files and the structure and comments were what convinced me TOML was worth to try. I did end up going back to JSON for the schema validator bit, but I just found out that TOML is still working on it: https://github.com/toml-lang/toml/pull/116
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.
JSON is good for data exchange. Configs? That's crazy talk.
Earlier quoted context omitted.
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…
Surely you shouldn’t be limited to types as interpreted and represented in the low-level config parser library but should have a strongly typed representation i of the config structure that you implement in whatever language you’re using. C# is a good example. JSON doesn’t have any of these types. It doesn’t even make a distinction between integers and other numbers. Yet it’s common practice to marshal these into the…
I mean .. yes, but that's the exact chaos we're trying to mitigate? The different types may all get serialised as strings, but their semantics are different. And the purpose of strong typing is to make it harder for people to put semantically wrong things in the wrong place.
(This is semantic markup vs all over again, isn't it)
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…
This is a table. Let's see it do a tree. (And not an adjacency matrix. That's cheating.)
To connect with the other threads, SQLite would be probably the best candidate proposed here to store a tree.