Toml: Tom's Obvious, Minimal Language

Re:Toml: Tom's Obvious, Minimal Language by Nadya on Friday July 13, 2018 @04:12PM (#17526282)

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.

[ Parent | on HN ]

Re:Toml: Tom's Obvious, Minimal Language by latk on Friday July 13, 2018 @04:46PM (#17526554)

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?

[ Parent | on HN ]

Re:Toml: Tom's Obvious, Minimal Language by Nadya on Friday July 13, 2018 @06:05PM (#17527232)

>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. :)

[ Parent | on HN ]

Re:Toml: Tom's Obvious, Minimal Language by xinau on Friday July 13, 2018 @04:49PM (#17526577)

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.

[ Parent | on HN ]