171–180 of 204 posts
> Whitespace means tab (0x09) or space (0x20). > Newline means LF (0x0A) or CRLF (0x0D0A). Complicating things from the start. Not a good sign.
And you can't expect windows users to always check their editor is lf compliant. Toml is not just for programmers
Does TOML have a schema?
Not currently, but it's something I'd like to add as a separate spec sometime later.
https://github.com/lantiga/clj-toml/blob/0.4.0-instaparse/sr...
What a lovely language! I may have to use it..
Earlier quoted context omitted.
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…
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…
Well, that's like your opinion, man.
If I have something set to some value in my configuration, I want those reading the configuration file (not parsing it, reading it in a text editor, e.g. to make an edit) to know why it's so.
>Applications should document their default settings in a different way
Comments in configuration files are not there to explain default settings, but to document why a setting (default or not, but usually already edit to suit your specific environment) has the value you set it to.
>Information about why a file contains those values belongs elsewhere, and it's an anti-pattern IMO to rely on comments in the config / param file.
That's a statement, not an argument. Why does it "belong elsewhere"? So that you have an extra layer, that few will bother to check?
Earlier quoted context omitted.
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 disagree. It’s an anti-pattern. For example, if you’re writing an application that loads a default config file to populate parameters at run time, then the software module that loads from the default file is the correct place to document it, because the meaning of defaults is relevant to that source code, not at all to someone reading the parameter file itself. A parameter file is just some blob of stuff. I agree c…
If you don't embed those comments you bereft that file of context -- why, as you admitted "is everything".
>Somewhere else, something has to choose to load that file, and that is where the documentation belongs (in addition to readable, separate artifacts that are generated from the file).
Well, that's not really relevant. People who change configuration are 99% of the time not the same as those who write/read/or even have access to the code that reads it.
Imagine Apache or Postgresql configuration for example.
Admins change those all the time, but don't have anything to do with the Apache or Postgresql project, and don't ever care to read their code.
On top of that, my particular settings in some config file, are based on MY local server and needs and my context, and not on something Postgresql or Apache devs will know themselves.
Earlier quoted context omitted.
{ “_comment”: “The comment goes here!”, “name”: “foo” }
So now your comments are flowing through infrastructure wasting bandwidth and possibly leaking internal configuration details?
And it’s not like there isn’t any potential problems with some YAML or TOML library you import. Rails Yaml comes to mind.
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…
Earlier quoted context omitted.
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…
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…
It's a horrible joke and I've yet to actually use it, but it makes me happy :)