3 ms·

Since Tom is browsing, I have a question - and this is my one and only major issue with TOML. # THIS IS INVALID a.b = 1 a.b.c = 2 Why? I'm sure

by Nadya 8y ago

Since Tom is browsing, I have a question - and this is my one and only major issue with TOML. # THIS IS INVALID a.b = 1 a.b.c = 2 Why? I'm sure there is very good reasoning - but it makes me have to reason about my data in a manner I consider backwards/confusing. name.first = "Bob" name.last = "Smith" # Can't do this because name.first has already been defined # name.first.alternative = "Robert" # This is too ambiguous name.alternative = "Robert" # And this is backwards to me name.alternative.first = "Robert" Some people might suggest to instead do first.name = "Bob" last.name = "Smith" alternative.first.name = "Robert" But now nothing is scoped to [name] and if I need to get the full name I can't just pull in [name] but need to pull in [first], [last], and [alternative]. That's really messy in my opinion. All of these are names and should be scoped to [name] and not their own structure.

latk 8y ago
Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c". Because it avoids these problems, your "name.alternative.first" example seems perfectly sensible to me. Alternatively, the name might be an array: [[name]] first = "Bob" last = "Smith [[name]] first = "Robert" It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples?
- Nadya 8y ago
  >Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c". Your explanation is perfect and I understand the justification why it isn't possible now - so thanks for that! The array alternative provided by xinau is also an acceptable replacement - maybe even better to be honest, especially in this particular scenario. >It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples? I came back from lunch and realized what I was trying to do didn't make sense while trying to convert it to JSON. Having name.first be both a value and contain an object doesn't make sense - unless it were to contain an array value but then why have the object and not just have the value? All very silly. So I guess my "only issue with TOML" is that I never sat down and tried to express what I wanted to express in any other way. It made a lot more sense in my head than on paper. :)
xinau 8y ago
I don't know if this is the intend of Tom, but I was also stumbling on this issue and the only reasonable explanation I can come up with is that: One key can't have multiple values with different types. For example in json: { "name" : { "first" : "Bob", "last" : "Smith" } } How would you add a "alternative" key to the "first" value type. The only way i can think of is something like this. { "name" : { "first" : "Bob", "first.alternative": "Robert", "last" : "Smith" } } or as @latk suggested, let "first" be an array, with it's first entry being the non alternatives. { "name" : { "first" : ["Bob", "Robert"], "last" : "Smith" } } I think this is by design. To quote @mojombo "simple configuration file that maps unambiguously to a hash table". But this is only a guess.

by Nadya 8y ago

latk 8y ago

Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c". Because it avoids these problems, your "name.alternative.first" example seems perfectly sensible to me. Alternatively, the name might be an array: [[name]] first = "Bob" last = "Smith [[name]] first = "Robert" It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples?

Nadya 8y ago
>Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c". Your explanation is perfect and I understand the justification why it isn't possible now - so thanks for that! The array alternative provided by xinau is also an acceptable replacement - maybe even better to be honest, especially in this particular scenario. >It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples? I came back from lunch and realized what I was trying to do didn't make sense while trying to convert it to JSON. Having name.first be both a value and contain an object doesn't make sense - unless it were to contain an array value but then why have the object and not just have the value? All very silly. So I guess my "only issue with TOML" is that I never sat down and tried to express what I wanted to express in any other way. It made a lot more sense in my head than on paper. :)

xinau 8y ago

I don't know if this is the intend of Tom, but I was also stumbling on this issue and the only reasonable explanation I can come up with is that: One key can't have multiple values with different types. For example in json: { "name" : { "first" : "Bob", "last" : "Smith" } } How would you add a "alternative" key to the "first" value type. The only way i can think of is something like this. { "name" : { "first" : "Bob", "first.alternative": "Robert", "last" : "Smith" } } or as @latk suggested, let "first" be an array, with it's first entry being the non alternatives. { "name" : { "first" : ["Bob", "Robert"], "last" : "Smith" } } I think this is by design. To quote @mojombo "simple configuration file that maps unambiguously to a hash table". But this is only a guess.