4 ms·
You seem pretty quick to disregard TOML. I switched all my JSON and YAML for TOML. Do you care to detail what is missing?
by svnpenn 6y ago
You seem pretty quick to disregard TOML. I switched all my JSON and YAML for TOML. Do you care to detail what is missing?
- atombender 6y agoTOML quickly breaks down with lots of nested arrays of objects. For example: a: b: - c: 1 - d: - e: 2 - f: g: 3 Turns into this, which is unreadable: [[a.b]] c = 1 [[a.b]] [[a.b.d]] e = 2 [[a.b.d]] [a.b.d.f] g = 3 TOML also has a few restrictions, such as not supporting mixed-type arrays like [1, "hello", true], or arrays at the root of the data. JSON can represent any TOML value (as far as I know), but TOML cannot represent any JSON value. At my company we use YAML a lot for table-driven tests (e.g. [1]), and this not only means lots of nested arrays, but also having to represent pure data (i.e. the expected output of a test), which requires a format that supports encoding arbitrary "pure" data structures of arrays, numbers, strings, booleans, and objects. [1] https://github.com/sanity-io/groq-test-suite/ https://github.com/sanity-io/groq-test-suite/
- svnpenn 6y agoLooks fine to me: [[a.b]] c = 1 d = [ { e = 2 }, { f = { g = 3 } } ]
- timClicks 6y agoAn improvement, but the original YAML is still significantly better, in my opinion.
- Arnavion 6y agoAlso many (most? all?) serializers don't let you control which fields are serialized inline vs not. So if you have a program that generates configuration, you're going to end up with the original unreadable form anyway.
- deleted 6y ago[deleted]