TOML: Tom's Obvious Minimal Language
1–10 of 229 posts
Re: TOML: Tom's Obvious Minimal Language
#2In case anyone is interested I made an online toml syntax checker in the same vane as jsonlint.com and yamllint.com:
Re: TOML: Tom's Obvious Minimal Language
#3The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
Re: TOML: Tom's Obvious Minimal Language
#4The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
Well that would be null right? an absence of the thing.
Re: TOML: Tom's Obvious Minimal Language
#5I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor.
That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do.
So context really comes into play here. I can see how this would be very useful for some programs, and near useless for others. And more specifically useful for those who consume user-edited configuration files.
Re: TOML: Tom's Obvious Minimal Language
#6The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
The Billion Dollar Mistake lives on.
Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't)
To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.
Re: TOML: Tom's Obvious Minimal Language
#7The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.
> The Billion Dollar Mistake lives on.
I disagree. There is a big difference between configuration language formats and programming languages.
> To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.
I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.
Re: TOML: Tom's Obvious Minimal Language
#8I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…
It also reminds me the syntax of INI files.
Re: TOML: Tom's Obvious Minimal Language
#9I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…
Curious at to what technologies you work with? The work that I do and tools that I use have all manner of configuration file syntaxes and languages and a big headache for doing sysadmin work is trying to remember if a particular .rc file uses INI, YAML, JSON, TOML or some home rolled nonsense.
Re: TOML: Tom's Obvious Minimal Language
#10JSON 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].