41–50 of 229 posts
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
Multi-line strings are another weakness. Sometimes you don’t\nwant\nto\nwrite\nthis\nway.
Funny thing: TOML author/inventor calls it a mistake: > TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read. > I personally abandoned TOML and as such, I'm not planning on adding any new features > If you're still reading, I'd like to pu…
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
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
now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all.
all this is so silly. we will stick with json and informal-ini forever one way or another.
I prefer KDL. It's like XML but with almost zero syntax. Probably not always the best idea because it's so niche but it's just really simple while having all the basics like comments and multiline strings.
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
The problem with comments in configuration files is that they don't survive a `load -> native object -> save` round-trip.
I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…
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
Earlier quoted context omitted.
I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.
Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.
It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.