Hi all, earlier I've naively tried to parse some toml code similar to this:
[fruits]
[fruits.apple]
color = "red"
[[fruits.apple.properties]]
name = "flavour"
content = "delicious"
[[fruits.apple.properties]]
name = "nutrition"
content = "abundant"
[fruits.apple.translations]
it = 'Mela'
fr = 'Pomme'
# dotted key
fruits.orange.color = 'orange'
which parses into this:
{
"fruits":{
"apple":{
"color":"red",
"properties":[
{
"name":"flavour",
"content":"delicious"
},
{
"name":"nutrition",
"content":"abundant"
}
],
"translations":{
"it":"Mela",
"fr":"Pomme",
"fruits":{
"orange":{
"color":"orange"
}
}
}
}
}
}
As you can see, the orange item spills inside apple's translations table, while I want it to be its own definition inside the fruits table. While it sounded right on paper, while re-reading the specification I noticed it says you cannot define a table more than once, which I assume it's what's happening here.
The code parses fine if I move orange to its own [fruits.orange] table and have color as a key of it, but is there a way to mix tables definitions and using inline dotted keys to define properties for that same table? My use case is that while apple would have a lot of properties, orange and some other fruit would only have the color key defined and therefore would be less verbose to quickly define it as a dotted key instead of building a table for each fruit.
Actually, nothing is defined twice in your example. Take note that you were still in the section [fruits.apple.translations] when you wrote fruits.orange.color = 'orange'. That's why you ended up with something looking like fruits.apple.translations.fruits.orange.
All [table] and [[table-element]] sections define absolute paths, and extend down to the next section (or EOF). The indentation doesn't mean anything. Sections are absolute, and dotted keys are relative to the section they're in, just like undotted keys.
You could move fruits.orange.color = 'orange' to the top-most section, before [fruits]. You'd have to define all the keys of fruits.orange there with more dotted keys, which isn't very flexible.
Another option is to write orange.color = 'orange' just after [fruits], which is legal, but it could get confusing. But you could, for instance, write banana.color = 'yellow' and strawberry.color = 'red' here, too.
Or you can start the [fruits.orange] section and write color = 'orange' inside it. That's the most flexible option, which you did discover. It's extra lines, but it's consistent with how [fruits.apple] is defined. And, it allows you to expand the fruits.orange table if you'd ever need to do that.
All [table] and [[table-element]] sections define absolute paths, and extend down to the next section (or EOF). The indentation doesn't mean anything. Sections are absolute, and dotted keys are relative to the section they're in, just like undotted keys.
Cheers, after that makes it's a bit easier to wrap my head around. I see that all "inline" solutions from this problem rely on the orange... dotted key being defined before or after specific element - since my .toml file is gonna be accessible by the end user for configuration purposes, I don't wanna include any examples that might lead them astray, so I'll define the [fruits.orange] table 馃槂
Thanks for taking the time to make this clearer!
Most helpful comment
Cheers, after that makes it's a bit easier to wrap my head around. I see that all "inline" solutions from this problem rely on the
orange...dotted key being defined before or after specific element - since my.tomlfile is gonna be accessible by the end user for configuration purposes, I don't wanna include any examples that might lead them astray, so I'll define the [fruits.orange] table 馃槂Thanks for taking the time to make this clearer!