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

141–150 of 173 posts

Re: TOML, Tom's Own Markup Language

#141

Post by draegtun »

dkersten wrote: post #9

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

It's because Larry Wall wanted something shorter than associative arrays.

* http://www.nntp.perl.org/group/perl.perl6.language/2007/05/m...

* http://www.nntp.perl.org/group/perl.perl6.language/2007/06/m...

Re: TOML, Tom's Own Markup Language

#143

Post by skrebbel »

mojombo wrote: post #107
skrebbel wrote: post #91

Given Jekyll's enormous backlog of issues and pull requests[0], can we expect this to be maintained or supported any bit beyond the late night drunken brain fart that this is? [0] https://github.com/mojombo/jekyll

Parker Moore and I (along with many contributors) have been spending quite a bit of time on Jekyll recently. Over the last 30 days we've merged 17 pull requests and closed 62 issues. We're ramping up for a 1.0 release and there's a brand new website in the works. You can check it all out on the master branch. Tens (or possibly hundreds) of thousands of people use Jekyll now. It's interesting to note that Jekyll start…

Cool. I'm very happy that you're back actively working on Jekyll! Guess my statement was a bit outdated then. Take it with the appropriately sized grain of salt.

Note: there's nothing wrong with releasing brain farts; quite the contrary. I didn't at all mean to imply that you shouldn't do that.

Re: TOML, Tom's Own Markup Language

#145

Post by icebraining »

dfkf wrote: post #140
icebraining wrote: post #124

Earlier quoted context omitted.

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…

Most of your points are environment specific and I think that you forgot the strongest of them - "xml APIs usually suck". In .net they are non-issues. And about being cumbersome and verbose, the point I tried to make is that you don't have to be zealous and put every small piece of data in a separate element. No reason not to put data in attributes or even in comma/whitespace separated strings, if that piece of data…

Most of your points are environment specific

How so? .Net can't magically discover the types of values or prevent developers from abusing the format.

you don't have to be zealous and put every small piece of data in a separate element.

But then you're layering a complex format with a custom application-specific parser, with an unknown syntax (e.g. spaces vs commas, are ranges supported, etc). It obviously can be done, but it's a mess.

Re: TOML, Tom's Own Markup Language

#146

Post by dkersten »

grey-area wrote: post #134
oleganza wrote: post #123

Earlier quoted context omitted.

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?

I agree Map or Dictionary would have been fine too, but it's so widely used it needs to be easy to type so two words is not great (HashMap). However I suspect it was just named that way following perl (written by an english speaker). Obviously it's far to late to change it now and I can't say it bothers me or most Ruby users. It's something you get used to very quickly.

So do what python did: dict

Though even HashMap isn't bad because typing is a solved problem - with auto completion and touch typing two words really aren't an issue in my mind.

People get used to living with all kinds of things, but that doesn't make them any better. Yes I'm aware that this applies equally to my typing comment as to you having got used to hash.

Re: TOML, Tom's Own Markup Language

#147

Post by GhotiFish »

Are arrays of maps a bad idea? Someone posted a pom.xml file pointing out how horrible it was, and I thought to myself "How would this look in toml?"

I was all set to try a translation when I hit this section:

  
    com.google.apis
    google-api-services-drive
    v2-rev53-1.13.2-beta
  
  
  
    
    com.google.apis
    google-api-services-plus
    v1-rev22-1.8.0-beta
    


  
    com.google.api-client
    google-api-client
    1.13.2-beta
  

  
    com.google.api-client
    google-api-client-servlet
    1.13.1-beta
How would I represent this in TOML?

  [dependancy1]
  groupId    = "com.google.api-client"
  artifactId = "google-api-client"
  version    = "1.13.2-beta"

  [dependancy2]
  groupId    = "com.google.api-client"
  artifactId = "google-api-client-servlet"
  version    = "1.13.1-beta"
That's not right, it clearly should be an array, but I don't think the standard supports it. At best I would think you'd have to use parallel arrays

  [dependencies]
  groupIds    = ["com.google.api-client", "com.google.api-client"]
  artifactIds = ["google-api-client"    , "google-api-client-servlet"]
  versions    = ["1.13.2-beta"          , "1.13.1-beta"]
and that's just not pretty.

Re: TOML, Tom's Own Markup Language

#148

Post by billpg »

GhotiFish wrote: post #144
billpg wrote: post #142

Dear industry, if you are going to add comments to JSON, please make it the /* */ variety.

Why? I dislike those comments.

Text editors will sometimes insert end-of-line characters in the name of word-wrap.

Using the end-of-line as a comment terminator would require significant refactoring of JSON parsers, which were previously at liberty to lump CR and LF together with SP and TAB. A starting and ending token, on the other hand, fits the pattern already required of a JSON parser.

Re: TOML, Tom's Own Markup Language

#149

Post by Gotttzsche »

LeafStorm wrote: post #133
cjh_ wrote: post #60

Earlier quoted context omitted.

>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?

I meant "only support homogeneous arrays," or "do not support heterogeneous arrays," and apparently got the two wordings mixed up. Thanks.

looks like you can put string arrays and int arrays into the same array though.

"data = [ ["gamma", "delta"], [1, 2] ] # just an update to make sure parsers support it"

so in a static language it would be like: Array> not sure this makes any sense

Re: TOML, Tom's Own Markup Language

#150

Post by rogerbinns »

nikcub wrote: post #40
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 parameter…

You can override in pretty much the same way TOML does. Instead of replacing an underlying object, you update it with the values read from JSON.
Post reply on HN