71–80 of 173 posts
It seems to me that YAML does this better already (with parsers which are already high-quality). If we want simplicity, then why not make sure it is a subset of YAML?
Agreed, I'd much rather have a normalized subset of YAML without the object serialization stuff (I don't even understand why it's there: why take a format intended to be read by humans and then muck it up with complex and dangerous object serialization notation).
I 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…
Parsing JSON for arbitrarily nested keys is nasty, and this makes it extremely natural.
And how is this better than xml?
I will note this isn't a valid XML document: you have no root node.
Urg. Off topic, but I dislike this perl/ruby tendency of calling hash tables hashes . When I see the word hash , I always think of a value (ie a hash code) and not a data structure. Why couldn't they call it a hash map, hash table, map, table, dictionary etc like all the other languages...?
I agree with that. 'map' or 'dictionary' are the best choices I think (or 'associative array', but why bring arrays into it). That's the interface, of which a hash table is just one possible implementation.
Earlier quoted context omitted.
please let's not bring XML into this. last thing we need is someone inspired to say let's all go back to XML.
Go "back"?! There are lots of places where xml is alive and well and config files is one of them. And you can see why - empty elements with attributes look rather concise, and without all that punctuation noise JSON has.
Earlier quoted context omitted.
That's not valid JSON either! (The second value has no key). Needs to be: { "because": [{ "80": "percent" }, {"of": "JSON", "is": "brackets" }] }
And this is only 10% curly braces, not counting spaces.
Earlier quoted context omitted.
I agree with that. 'map' or 'dictionary' are the best choices I think (or 'associative array', but why bring arrays into it). That's the interface, of which a hash table is just one possible implementation.
I've never liked 'dictionary'. The analogy isn't at all apparent to me. A dictionary explains what words means. The thing we're talking about doesn't explain what keys mean. (Someone who spends most of his time writing python here.) 'map' or 'mapping'.
Earlier quoted context omitted.
I agree with that. 'map' or 'dictionary' are the best choices I think (or 'associative array', but why bring arrays into it). That's the interface, of which a hash table is just one possible implementation.
I've never liked 'dictionary'. The analogy isn't at all apparent to me. A dictionary explains what words means. The thing we're talking about doesn't explain what keys mean. (Someone who spends most of his time writing python here.) 'map' or 'mapping'.
I 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…
Tom's not being arrogant; he's just being irreverent.