21–30 of 204 posts
(Well, I guess there's not that much to win/lose in the area of config languages, but still) (Also, I think it works pretty well, so this is not to downplay TOML!)
In my opinion, one of the more useful features was the addition of Joda-style datetimes [2][3][4][5], which disambiguates between various kinds of datetime constructs aren't interchangeable yet commonly conflated. It's fair criticism that the addition of rich datetime types exceeds the language's original 'minimal' goal, but too many other languages and formats these days just punt to RFC3339 and leave no guidance or tooling on how to represent dateless times or timeless dates without introducing a ton of side-effects. This is a place where language standard libs, with few exceptions, have repeatedly dropped the ball, and similarly, language or library-agnostic, generic guidance is nowhere to be found.
TOML raises the bar here, by providing a concept and notation to specify these values at rest, and gives parser writers, as opposed to the users, the task of finding a way to represent these values in whatever way is idiomatic for the given language.
[1] https://github.com/toml-lang/toml/blob/master/CHANGELOG.md [2] https://github.com/toml-lang/toml/pull/414 [3] https://github.com/toml-lang/toml/pull/362 [4] https://github.com/toml-lang/toml/issues/412 [5] https://github.com/toml-lang/toml/issues/263
Earlier quoted context omitted.
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
indicates an 'open' array ?
{
"designers": [
{"name": "Guido", "lang": "Python"},
{"name": "Larry", "lang": "Perl"}
]
}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…
1. Would a file path type make any sense to add? TOML is ideal for configurations, and so many configuration options use file paths. I know there are questions about platform dependency, and I don't have all the right answers for how that would work, but I could see it being possible somehow?
2. Data versioning is a big deal to me. For now there's always an option of just adding a "version" key and updating it, but can you think of a better way to do that with TOML?
I'm always overly critical of JSON (despite overall being a fan) because it doesn't specify bit sizes of numbers. I notice that TOML has specified 64 bit numbers. It's nice to see that.
Does anyone know why such a "joke proposal" (as stated by the author itself) was chosen for pretty significant projects like pip and cargo? (edit: I tried to say it began as something small and personal) (Well, I guess there's not that much to win/lose in the area of config languages, but still) (Also, I think it works pretty well, so this is not to downplay TOML!)
I think the moral of the story is: just put your whacky ideas out there and see what happens. You never know when you'll hit a chord.
In any case I'm glad to see it in several open source projects (Mailtrain for example). It's so much easier to read for humans than JSON.
http://www.businessinsider.com/github-harassment-story-2014-...
https://blog.github.com/2014-04-21-results-of-the-github-inv...
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…
Hi Tom, huge fan of this project. 1. Would a file path type make any sense to add? TOML is ideal for configurations, and so many configuration options use file paths. I know there are questions about platform dependency, and I don't have all the right answers for how that would work, but I could see it being possible somehow? 2. Data versioning is a big deal to me. For now there's always an option of just adding a "v…
2. This is still a big question, and we've been having a robust argument about it on GitHub [1]. It's a problem that so far has evaded an elegant solution, but usually when that's the case, it just means we haven't been creative enough about it yet! Or did you mean versioning of the data IN the config file? Can you elaborate?
Homogeneous arrays can come in the following forms
- Shallow, literal type (a list of lists, regardless of the nested lists contain)
- Full, literal type (a list of dicts of strings)
- Logical type
There are many times where a list is the best type for my data but I want to take advantage of logical types for easier configuration by my users.
Below is an example of what I mean by "homogeneous logical types":
`Cargo.toml` has you specify dependencies using a dict
[dependencies]
foo = { "version" = "1.0" }
[dependencies]
foo = "1.0"
enum Dependency {
Version(String),
Specification(HashMap),
}