Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML, Tom's Own Markup Language

github.com

Post reply on HN
Print view View original

31–40 of 173 posts

Re: TOML, Tom's Own Markup Language

#31

Post by Comkid »

mikegirouard wrote: post #22
Comkid wrote: post #15

Would 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.

Would it be okay to understand arrays as integer indexed keys?

For example, wouldn't that mean something like:

  array = [ [1,2], ["a", "b"] ]
Be the same as this:

  [array]
  0 = [1,2]
  1 = ["a", "b"]

Re: TOML, Tom's Own Markup Language

#32

Post by krapp »

mikegirouard wrote: post #26
mostly_harmless wrote: post #17

I'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.

I would prefer INI over JSON as well except that JSON lets me nest arrays and INI doesn't. So this looks really nice.

On the other hand I'd like to mix my data types as much as I darn well please.

Re: TOML, Tom's Own Markup Language

#33

Post by tzury » 

    Because we need a decent human readable format 
    that maps to a hash and the YAML spec is like 
    600 pages long and gives me rage. No, JSON 
    doesn't count. You know why.
I do not know why, And would love if one can explain me?

Other than comments, I see not difference between both.

Also, that human readable is not an accurate, as it should be hacker readable, you know, IT folks are the only target audience of those files.

    [owner]
    name = "Tom Preston-Werner"
    organization = "GitHub"
    bio = "GitHub Cofounder & CEO\nLikes tater tots and beer."
    dob = 1979-05-27T07:32:00Z # First class dates? Why not?


    {
        "owner": {
            "name": "Tom Preston-Werner",
            "organization": "GitHub",
            "bio": "GitHub Cofounder & CEO\nLikes tater tots and beer.",
            "dob": "1979-05-27T07:32:00Z"
        }
    }

Re: TOML, Tom's Own Markup Language

#34

Post by zwegner »

benatkin wrote: post #20
stdbrouw wrote: post #12

Earlier quoted context omitted.

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.

Yes, and I think it's arrogance on the part of Wordpress (there I did it) folks to insist that everyone capitalize it in the prescribed manner. Especially since they weren't consistent from the get-go. They even went so far as to make Wordpress (trolol) itself filter content to be capitalized if someone tries using the lower case p. http://justintadlock.com/archives/2010/07/08/lowercase-p-dan...

Hehe, that reminds me of iphones auto-correcting "iphone" to "iPhone". Jeez that would irritate me, I'm trying to write a text message, not look like an iDouche...

Re: TOML, Tom's Own Markup Language

#35

Post by zwegner »

LeafStorm wrote: post #3

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'm just wondering what the point of having homogeneous arrays is when the dictionaries aren't...

Re: TOML, Tom's Own Markup Language

#36

Post by nightpool »

LeafStorm wrote: post #3

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 don't know if you can call him "arrogant". None of it read as very serious to me, I more assumed he was just having fun.

Re: TOML, Tom's Own Markup Language

#37

Post by DanielRibeiro »

tzury wrote: post #33

Because we need a decent human readable format that maps to a hash and the YAML spec is like 600 pages long and gives me rage. No, JSON doesn't count. You know why. I do not know why, And would love if one can explain me? Other than comments, I see not difference between both. Also, that human readable is not an accurate, as it should be hacker readable, you know, IT folks are the only target audience of those files.…

In the authors own words[1]:

{ 'because': { '80': 'percent' }, {'of': 'JSON', 'is': 'brackets' } }

[1] https://github.com/mojombo/toml/issues/2#issuecomment-140029...

Re: TOML, Tom's Own Markup Language

#38

Post by kingkilr »

tzury wrote: post #33

Because we need a decent human readable format that maps to a hash and the YAML spec is like 600 pages long and gives me rage. No, JSON doesn't count. You know why. I do not know why, And would love if one can explain me? Other than comments, I see not difference between both. Also, that human readable is not an accurate, as it should be hacker readable, you know, IT folks are the only target audience of those files.…

In JSON that datetime won't deserialize to a datetime instance in your language in a conforming parser. Further JSON has no comments (this is a killer for a configuration format).

Re: TOML, Tom's Own Markup Language

#39

Post by wvenable »

rogerbinns wrote: post #24

What 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.

Lack of comments is pretty much a deal breaker for configuration. I see a lot of undocumented JSON used for configuration and I find it difficult to believe that is something we want for the future.

Lack of comments makes JSON much better for data exchange than formats with comments.

Re: TOML, Tom's Own Markup Language

#40

Post by nikcub »

rogerbinns wrote: post #24

What 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.

A few issues (although I do use JSON in config):

It isn't a friendly form of human input. My error rate is 50%+ , you have to lint on save to catch things that are invisible to the naked eye

No ability to override, extend or reference keys. This is most useful in config objects where for eg. in a dev object you want to override the username and password for a database connection but not repeat all the other parameters

No comments

Post reply on HN