TOML – Tom's Obvious, Minimal Language
1–10 of 163 posts
Re: TOML – Tom's Obvious, Minimal Language
#2Modding command and conquer through "rules.ini" was always an adventure.
Re: TOML – Tom's Obvious, Minimal Language
#3I 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. You can't even have trailing commas in a list!
Re: TOML – Tom's Obvious, Minimal Language
#4Such 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 arrays.
Most disappointingly, TOML has a "table" type, but unfortunately, just like other "RPC as Config" formats, the column names need to be repeated for every row, which is just crazy. It also makes no sense to talk about "arrays of tables", which are actually just "rows" in standard terminology. An array of rows... is a table.
Here is a terse example of the type of thing that does come up very often in bulk provisioning of the type that needs config files full of data:
@"
Server,Subnet,IP
db01,databases,10.1.2.3
db02,databases,10.1.2.4
user01,filers,10.3.10.1
user02,filers,10.3.10.2
"@ | ConvertFrom-Csv | New-VMBuildScript.ps1
I'm yet to see a config file format that can even approach this in terms of its readability and terseness.Re: TOML – Tom's Obvious, Minimal Language
#5TOML 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…
The example you give would suck in any configuration file format, and honestly I don't believe it belongs in a configuration file - I'd put it into a data file (e.g. a CSV as you show) and then in the configuration file I'd include a pointer to that data file to be loaded separately.
Re: TOML – Tom's Obvious, Minimal Language
#6TOML 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…
Re: TOML – Tom's Obvious, Minimal Language
#7TOML 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…
It looks like you have tabular data where you don't need any nesting, every row has the exact same structure, and there's no single column of a row that you'd call "the value." TOML is not well-suited for this, and I don't think it sets out to be. I see how you'd call it "configuration," but it seems like a pretty different category of thing.
(I'd buy the argument that "table" is a poor choice of name for that TOML construct; I'd personally have called it a "multi-value" or something. It's an array of objects, and there's no guarantee that the objects have homogeneous structure, and it's usually useful for them to have different structures.)
Re: TOML – Tom's Obvious, Minimal Language
#8Re: TOML – Tom's Obvious, Minimal Language
#9Re: TOML – Tom's Obvious, Minimal Language
#10They all have warts because using the same symbolic notation for data and structure leads to encoding issues that have cognitive overhead.
So instead of getting used to the pratfalls involved in making mistakes in one format/library set, we can do it in a whole bunch of different ones. And of course if anyone uses the new format much much, we'll get multiple, slightly incompatible versions, all with different bugs.
Thanks?