- Visualizer:
- Code:
- TOML spec:
I really don’t understand why people still insist on prohibiting trailing commas anywhere. The syntax is interesting but it looks like defining an array of objects would be needlessly difficult.
Submitted 9 months ago by ruffsl@programming.dev to programming@programming.dev
https://www.youtube.com/watch?v=n9mGk8_tQtM
I really don’t understand why people still insist on prohibiting trailing commas anywhere. The syntax is interesting but it looks like defining an array of objects would be needlessly difficult.
but… trailing commas are ok in TOML.
The double square bracket is for an array of tables. A regular array looks “normal”: toml.io/en/v1.0.0#array
Every time I have reached for TOML I have ended up using JSON. The first reason is that Python standard library can read but not write TOML, which is generally useless for me. The second reason is all values are strings. The third reason is TOML does not add any benefit over JSON. It’s not that much easier to read and IMO JSON is easier to write by hand because the syntax rules are completely obvious.
TOML is mainly for humans to write, certainly not a good choice if you’re programmatically writing files - comments and formatting would be lost.
So it’s good for things that don’t change, or things you have to change by hand, which gives it almost zero utility for any project that I’ve worked on.
Just gonna throw out HJSON as another alternative: hjson.github.io
I thinks a great idea but I have never seen it used in the wild, unforunately.
Why would one pick toml over yaml?
Xkcd 927?
What?
It’s simple and readable. You literally put somebody that has never coded in their life, show them the YAML file and they will probably get it.
In Toml there are too many ways to do the same thing, which I don’t like. Also unless you know it deeply, you have no idea how the underlying data structure is going to look.
Yaml is already pretty popular, so I don’t think 927 applies here. It’s actually more common in newer projects than toml.
Which begs the question, should I go with the flow or is there good reason to go with toml?
XML < YAML < TOML
noyaml.com
Perhaps they’re Norwegian.
Significant whitespace is the devil’s play thing.
The code link is cut off for me
I like the syntax so much, but I’m so missing variables like the ones in ConfigParser’s .ini
format, I wish there was a good format where they’re actually standard
I’ll never understand why we don’t just use s-expressions.
NewPerspective@lemmy.world 9 months ago
TOML and YAML both have the problem that if you receive an incomplete document, there’s a decent chance you can’t tell. JSON doesn’t have that because of the closing curly.
AMDmi3@lemmy.world 9 months ago
That’s not a problem of a format and should be handled by transport or storage.
Turun@feddit.de 9 months ago
It very much is an aspect of the format. You may deem it unimportant, but it’s a feature that is missing from toml and yaml.
NewPerspective@lemmy.world 9 months ago
What about processes that terminate before writing the whole thing? You can’t protect against everything. Blame other processes all you want but the language spec allows for confusion.
suy@programming.dev 9 months ago
Doesn’t YAML have a (seldom used) feature of a start and end of document marker? The “YAML frontmatter” that a few markdown documents have, uses this.
EmergMemeHologram@startrek.website 9 months ago
On the other hand, I hate that with JSON you can only surge one document per file.
Some programs allow you to omit the outside braces, others require it.
But I do hate toml, and I don’t much like yaml either (why are there like 8 whitespace permutations?!)
Azzk1kr@feddit.nl 9 months ago
What’s wrong with TOML? I personally think it’s great for configuration purposes.
RubberElectrons@lemmy.world 9 months ago
Good point, I’d been interested in using toml