201–210 of 229 posts
Earlier quoted context omitted.
Key not being present is no value, key present has value, empty string or otherwise, seems simple enough. You can add advanced semantics on load, the file does nothing by itself after all.
It’s that “or” that bites you if you aren’t real sure of the semantics in play.
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
Apple's XML plist format seems like a mistake, though maybe the newer JSON format is OK.
> JSON is basically perfect if it allowed trailing commas and comments
Apparently Apple actually supports JSON5, an extended JSON based on ES5 that allows trailing commas, comments, and (my favorite!) unquoted key names, among other convenient features.
Earlier quoted context omitted.
As much as it pains me to say so, this is probably fine for configuration languages so long as they’re backwards compatible. Eg toml is used by rust’s cargo tool. Cargo can just say “hey Cargo.toml is parsed in toml version 1.1 format”.
How does your IDE and linter learn that? In fairness it's probably not too bad as long as everyone actually migrates to the newest version eventually... But that isn't guaranteed - look at YAML. Or even JSONC. VSCode has a hard-coded lists of which `.json` files are actually JSONC. Gross.
Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…
How does this deal with needing to represent nested data? (the example coming to me now is TOML as a list of libraries each of which has a number of dependencies). I guess you can always do it by duplication, but for a human oriented format, that sounds pretty painful.
As a human, I prefer to edit by hand an unordered list of key-value pairs (even if the keys are long), than a json object. I often find myself using gron/ungron to edit json data by hand in a comfortable manner. The fact that several implementations of gron exist suggests that I'm not alone in this preference. Editing json requires a global understanding of the structure. But on a list of keys/values there is no order, and each line stands for itself and is understandable in isolation.
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.
I disagree. TOML is an INI replacement. They both suck at nested structures but are good if you just have a load of top level sections containing simple key-values. 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.
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
published data standards having version is so wrong. 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 infor…
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
Here's the toml.io example in perfectly legal YAML but using only YAML's nicer, JSON-like, compatibility grammar:
title: "TOML Example"
owner: {
name: "Tom Preston-Werner",
dob: 1979-05-27 07:32:00 -08:00
}
database: {
enabled: true,
ports: [8000, 8001, 8002],
data: [
["delta", "phi"],
[3.14]
],
temp_targets: { cpu: 79.5, case: 72.0 }
}
servers: {
alpha: { ip: "10.0.0.1", role: "frontend" },
beta: { ip: "10.0.0.2", role: "backend" },
}
Multi-line strings in YAML are also very similar to TOML and you can ignore all different character mixups and stick to '|' (w/ newlines) and '"' (no newlines).
# same as " hello world! "
str1: "
hello
world!
"
# same as "apples\noranges\n"
str2: |
apples
oranges
# integers
int1: +99
int2: 42
int3: 0
int4: -17
# hexadecimal with prefix `0x`
hex1: 0xDEADBEEF
hex2: 0xdeadbeef
# octal with prefix `0o`
oct1: 0o01234567
oct2: 0o755
# fractional
float1: +1.0
float2: 3.1415
float3: -0.01
# exponent
float4: 5e+22
float5: 1e06
float6: -2E-2
# both
float7: 6.626e-34
# infinity
infinite1: .inf # positive infinity
infinite2: +.inf # positive infinity
infinite3: -.inf # negative infinity
# not a number
not1: .nanEarlier quoted context omitted.
If it has a decimal point then it is a decimal. And if it doesn't (or if it only has zeros after the point) then it's an integer. JSON is absolutely unambiguous as to the actual numerical value - how badly that gets translated into the decoding language is entirely on that language.
This isn't right. JSON can also store exponential numbers (eg {"google": 1e+100}). You could decode this to an arbitrary-sized BigInt, but I can make you waste an arbitrary number of bytes in RAM if you do that. And even then, "look for a decimal point" doesn't give you enough information to tell whether the number is an integer. Eg, 1.1e+100 is an integer, and 1e-100 is not an integer. One of JSON's biggest benefits…
Earlier quoted context omitted.
--flagfile gets me really far but to be fair it sucks when you need nested kv
just use longer keys (with an ad-hoc separator, if you want)
--allowed-downtime-0-start=20230523170000Z
--allowed-downtime-0-end=20230523170500Z
--allowed-downtime-1-start=...
--allowed-downtime-start='20230523170000Z,...'
Genuine question, as I actually like the plain old flagfiles/Java-properties-ish style.
I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but…
I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.