Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toml: Tom's Obvious, Minimal Language

github.com

Post reply on HN
Print view View original

121–130 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#121

Post by Nadya »

latk wrote: post #105
Nadya wrote: post #99

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 ambiguo…

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 T…

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

Re: Toml: Tom's Obvious, Minimal Language

#122

Post by spondyl »

gregn610 wrote: post #92
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

JSON used to support comments but they started being used for unintended things like parsing directives.[0]

It is apparently possible to include, and then remove them before usage apparently but I've never tried.

[0]: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

Re: Toml: Tom's Obvious, Minimal Language

#123

Post by dmurray »

Waterluvian wrote: post #110
mlthoughts2018 wrote: post #109

Earlier quoted context omitted.

I used to feel this way, and also used to be frustrated about multi-line strings in JSON. With years of experience now, though, I actually appreciate JSON omitting these features. Config files should absolutely not have or need comments. If you need them directly in the config file, something is wrong. Applications should document their default settings in a different way, preferably in a README or generated document…

I have never disagreed with someone more than I do now. =) Config absolutely needs comments. Context is everything. Comments allow me to explain to other humans why the config is the way it is. Dumping that out to a separate file is begging for it to fall out of sync when there's no comment instructing anyone to go and update the other file. Plus that's just kind of silly.

I would even say config needs comments more than code does. Code can be self-documenting: by using good variable and function names, splitting or combining lines of code, or re-ordering blocks of code you can often make the intent of the code clearer without adding explicit comments. If you do something unexpected in a config file, it likely just shows as setting some name to a magic number or a magic string.

Re: Toml: Tom's Obvious, Minimal Language

#124

Post by adrusi »

alokitr wrote: post #94
gregn610 wrote: post #92

Earlier quoted context omitted.

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

> I found the double square bracket syntax useful and understandable Really? I had kind of the inverse reaction to it. Indeed useful, but definitely not understandable

It's kind of similar to the syntax of uri query strings and the php syntax for appending to arrays, in that an extra pair of square brackets indicates appending:

In php:

    $a[] = 1;
    $a[] = 2;
    # $a == array(1, 2)
In URIs:

    http://example.org/?a[]=1&b[]=2
Compare to TOML

    [[a]]
    item = 1

    [[a]]
    item = 2

Re: Toml: Tom's Obvious, Minimal Language

#125

Post by majewsky »

adrusi wrote: post #124
alokitr wrote: post #94

Earlier quoted context omitted.

> I found the double square bracket syntax useful and understandable Really? I had kind of the inverse reaction to it. Indeed useful, but definitely not understandable

It's kind of similar to the syntax of uri query strings and the php syntax for appending to arrays, in that an extra pair of square brackets indicates appending: In php: $a[] = 1; $a[] = 2; # $a == array(1, 2) In URIs: http://example.org/?a[]=1&b[]=2 Compare to TOML [[a]] item = 1 [[a]] item = 2

That URI syntax is just a convention used by some web frameworks. You can just as well write

  https://example.org?foo=bar&foo=baz

Re: Toml: Tom's Obvious, Minimal Language

#127

Post by suby »

spondyl wrote: post #122
gregn610 wrote: post #92

Earlier quoted context omitted.

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

JSON used to support comments but they started being used for unintended things like parsing directives.[0] It is apparently possible to include, and then remove them before usage apparently but I've never tried. [0]: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

I'm personally doing something similar in a C++ project that I'm working on. I designate comments with a //. When I load the JSON file, I go line by line removing comments as I find them. Once the file is parsed you can feed it into any regular JSON parser (personally I'm a fan of https://github.com/nlohmann/json).

Using JSMin would have been a much better idea. At this point though the only downside is that I haven't yet done this for saving JSON. It's a harder problem but I don't see why it wouldn't also be doable.

edit: Apparently this library allows you to have comments, and will even preserve them when saving the JSON file.

https://github.com/open-source-parsers/jsoncpp

Re: Toml: Tom's Obvious, Minimal Language

#128

Post by ci5er »

mlthoughts2018 wrote: post #109
gregn610 wrote: post #92

Earlier quoted context omitted.

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

I used to feel this way, and also used to be frustrated about multi-line strings in JSON. With years of experience now, though, I actually appreciate JSON omitting these features. Config files should absolutely not have or need comments. If you need them directly in the config file, something is wrong. Applications should document their default settings in a different way, preferably in a README or generated document…

> I actually appreciate JSON omitting these features.

I guess this is right if config files are only machine read and written. When I am prototyping, config auto-gen tends to come pretty late in the project (for me), and I like being able to comment things.

I also like types and time-date parameters (which JSON doesn't provide unambiguously), so by the time I've done, I've reinvented YAML+, and that's a mess, so I actually appreciate TOML quite a bit... (At the very least - I get to be a retard[0] about config later in the process)

[0] To the inevitable person that's going to call me an able-ist for using the term, I'm using the term in a self-denigrating way, ...

Re: Toml: Tom's Obvious, Minimal Language

#129

Post by btilly »

KirinDave wrote: post #97
btilly wrote: post #84

Earlier quoted context omitted.

You aren't going to change what people around here like. And complaining about downvotes usually just attracts more. If you think that your brand of funny is worth braving people's disapproval, do it knowing what the reaction is going to be. If you don't like people disapproving, then go elsewhere, or engage here in a way that people prefer.

I made the joke for Tom. It has special significance for him.

That's fine then. Make the joke for Tom. Ignore the inevitable downvotes. Nobody else has to understand or like it.

Re: Toml: Tom's Obvious, Minimal Language

#130

Post by CMay »

mojombo wrote: post #49
stevefan1999 wrote: post #47

Earlier quoted context omitted.

This project reminds me of the good old INI files.

As it should! It was inspired by INI, but with a desire for a proper spec that unambiguously maps the config file to a hash table.

This was the first thing I noticed as well. It was always somewhat alienating when encountering newer formats that were less friendly than what came before. I think TOML does a good job of taking what came before and bringing it forward.

Over the many years of the usage of INI I think occasionally we've seen developers add their own touches to how they support types, sections, groups, multi-dimensional arrays or other structures within config files that certainly indicated a need for some more standardized advancement here.

I really hope this gains a lot of traction, because there are so many scenarios where things like XML or JSON are forced into roles they really don't belong in.

One thing that I would say is that it might be worth indicating a standard header that can be used at the very least in cases when it is not stored in a file with a .toml extension. It would not surprise me at all to see TOML widely used with extensions that describe better the intent of the file rather than the format.

Post reply on HN