131–140 of 173 posts
Working node.js version: https://github.com/aaronblohowiak/toml I just need to auth and push it to npm.
Nice work! It's too bad that this guy squatted on the `toml` package name without any implementation: https://github.com/BinaryMuse/toml-node
This is quite nice but there are a few of things that I miss: 1. A way to have multi-line values for non array types 2. A more flexible number syntax (e.g. allow hex and binary integers, allow exponents on floats, allow NaN and +/-Inf) 3. Make it possible to have an extra comma after the last element on an array (as in Python) 4. Add a way to "include" another config file #1 is important because some projects require…
It's not just in the diffs. Trailing commas make editing the list easier.
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…
>I realized it aided compatibility with languages that do not support homogeneous arrays. Don't you mean languages that only support homogeneous arrays (or languages that do not support non-homogeneous)? As the spec says that the array elements must all be of the same type, thus homogeneous. If I a mistaken, can you please explain why?
Earlier quoted context omitted.
Because the primitive is called Hash my %hash = (); Hash.new So naturally people talk of Hashes etc. I understand where you're coming from, but it's really not very important, and it would be more confusing to talk of Hash Tables as learners would naturally look for HashTable in the stdlib.
That was the question: why the class is named Hash instead of HashMap or Dictionary? Was it done intentionally, or it is just an accident because someone did not know English very well?
> 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.
And two ways to indent.
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…
The biggest concern with JSON seems to be the lack of comments. So what voodoo is Sublime Text 2 performing? Why can't we just use that? { // Sets the colors used within the text area "color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme", // Note that the font_face and font_size are overriden in the platform // specific settings file, for example, "Preferences (Linux).sublime-settings". // Because of this…
Douglas Crockford himself suggests you "Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." That sounds like a reasonable workaround.
https://plus.google.com/118095276221607585885/posts/RK8qyGVa...
I'll be the first to ask: whats wrong with JSON?
Ah, the power of fame. Implementations spreading like weeds. Four already in javascript, even though the spec is not anywhere near finished: npm search toml npm http GET https://registry.npmjs.org/-/all/since?stale=update_after&startkey=1361700343737 npm http 200 https://registry.npmjs.org/-/all/since?stale=update_after&startkey=1361700343737 NAME DESCRIPTION AUTHOR DATE node-toml TOML parser =ricardobeat 2013-02-24…
And how is this better than xml?
Let's see: . No native support for numbers, dates, booleans or lists. The latter can be implemented using subelements, but it's so cumbersome that you skimped on that and used a non-typed string instead (the database ports). . Redundant verbosity. Root elements, closing tags, way too much crap to be manually inserted. . XML parsers are huge, complex beasts which have no place in many smaller applications. . Being XML…