91–100 of 229 posts
My main issue with TOML is precisely described in the homepage example: [servers] [servers.alpha] is error prone. An sub heading shouldn't need to know about its parent, much less to have to copy it entirely.
Earlier quoted context omitted.
CSS has two magic values that would be useful in many configuration scenarios: - unset: ignore values of this property - initial: use the default value These would be useful e.g. with overrides. I agree that nulls in a config files are often not a good idea because it is not clear how they are going to be interpreted. PS: Css also has inherit that could mean "use the local default" while initial could mean use system…
Unfortunately that's not what `unset` does and I feel like the confusion it causes and the complication it adds to any CSS parser suggests it's a bad idea!
They are about as useful in a configuration language, where the cascading logic also applies.
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516
That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904
I wonder why text protobuf is not widely used for config. There is a formal description of the structure and the configuration structure can be statically checked.
JSON support is often in a language’s standard library, or close, and its ambiguity around what numbers you can actually use can be seen as a worse-is-better approach.
(There are similar tradeoffs with not specifying a max length of a string. It’s awkward, nit-picky, and error-prone to pick a maximum, but there are practical reasons you don’t want to allow unlimited lengths in a UI.)
Rather than a JSON replacement, I like TOML as a YAML replacement. It's a lot simpler, I'm not confused by things not having a preceding dash, indentation isn't significant, etc.
YAML on the other hand is just as good at any nesting depth. I mean it's pretty awful at all depths, but the act of nesting doesn't make it any more awful.
Earlier quoted context omitted.
There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values. It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.
In my experience (Python and Rust) missing keys are errors, not silently converted to None: In [1]: example = {"foo": None} In [2]: print(example["foo"]) None In [3]: print(example["bar"]) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) Cell In[3], line 1 ----> 1 print(example["bar"]) KeyError: 'bar' In [4]: print(example.get("bar", "sensible defa…
Earlier quoted context omitted.
That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904
How do you know which version you are using though?
TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is.
I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes.
My main issue with TOML is precisely described in the homepage example: [servers] [servers.alpha] is error prone. An sub heading shouldn't need to know about its parent, much less to have to copy it entirely.
How do you convert it into a nested object then? You could use deeply nested objects like JSON or YAML does, but then it defeats the purpose of an easy to read configuration format. This is also a feature of Java property files.
To the very best of my knowledge, Properties are merely Map (see: https://docs.oracle.com/en/java/javase/11/docs/api/java.base... ) and any subsequent interpretation happens in the application (e.g. Spring treating `foo[1]=bar` as a list-ish assignment but the actual key returned from `getProperty` is the string literal as written `foo[1]`)