> There should only be one way to do anything.
[...]
> There are two ways to make keys.
I guess I haven't had enough whiskey yet.
TOML, Tom's Own Markup Language
21–30 of 173 posts
Re: TOML, Tom's Own Markup Language
#22Would this be considered legal? [ [1,2], ["a", "b"] ]
The README says not to mix data types because "that's stupid" (which I don't know if I agree with); but I don't know if that answers your question.
You have an array of array, which at that level, satisfies the spec. The children individually keep types contained.
That said, I'm going to assume the intent is to not allow that.
Re: TOML, Tom's Own Markup Language
#23I note that, like many erstwhile specs, TOML does not document the escape sequences accepted in strings. Nor does it exhaustively specify integer formats and float formats - rather ironic for a spec that advertises "TOML is designed to be unambiguous and as simple as possible." The limitation on array types seemed fairly arbitrary at first glance, but after thinking it over I realized it aided compatibility with lang…
Well, he's the CEO of Github, and he's probably been drinking, so I suppose a little bit of arrogance is expected.
The type of person who is arrogant while drunk is generally arrogant while sober as well ...
Re: TOML, Tom's Own Markup Language
#24What is wrong with JSON? Everything already supports it.
JSON has two drawbacks: a lack of comments (although you could add "#" keys in relevant places) and no binary support (arbitrary conventions include base64) but this doesn't support binary anyway.
Re: TOML, Tom's Own Markup Language
#25Earlier quoted context omitted.
For the love of baby jesus why can't people get the 'H' right.
As proper nouns become more common, they first lose any capitalization in the middle of the word, and then finally capitalization of the initial letter. It's human language. It happens.
Especially when their own logotype has it in all lowercase.
Re: TOML, Tom's Own Markup Language
#26I'll be the first to ask: whats wrong with JSON?
IMHO, although it's very easily readable by humans, it's not quite as easily written by humans.
I've always preferred INI over JSON for this reason.
Re: TOML, Tom's Own Markup Language
#27Don't want to be a naysayer, but what's wrong with something like CSON (CoffeeScript Object Notation)?
Re: TOML, Tom's Own Markup Language
#28Ruby parser here: https://gist.github.com/jm/5022483 Please fork and improve. :)
# line 36 text.split("#").first This will have trouble with a line like: tweet = "TOML is #awesomesauce" -- # line 43 array = $1.split(",").map {|s| s.strip.gsub(/\"(.*)\"/, '\1')} You should recurse into coerce here, or you'll just lose types. (Also you're assuming arrays of strings.) array = $1.split(",").map {|s| coerce(s) } -- You're also not dealing with nested key groups. (eg. [servers.alpha]). -- That being sa…
Yup array handling is weak. I was going to recurse into coerce, but then the examples made it seem like only strings will be accepted in arrays (he put "8000" in there rather than just 8000). I'll get clarification.
Made it into a proper project/gem here if you want to file issues: https://github.com/jm/toml
And good call on the nested key groups. Shouldn't be hard to knock that out.
Re: TOML, Tom's Own Markup Language
#29Would this be considered legal? [ [1,2], ["a", "b"] ]
I wondered the same thing. "No, you can't mix data types, that's stupid" leaves it ambiguous.
If you parse the outer array as just "array of arrays" (as each element is an array), you're not "mixing". But if we're supposed to be parsing it as "arrays of arrays of _type_", then we are mixing.
Re: TOML, Tom's Own Markup Language
#30I'll be the first to ask: whats wrong with JSON?
Nothing, json's awesome. But like most data packaging schemes the finished product isn't designed with human-readability as a primary goal.
Edit: as mikegirouard points out it is much easier to read than (for example) serialized data, but still not as friendly as ini.