3 ms·

Then the parser might fail, and rightly so. A comment lower down shows it failing in a simple parser in go: https://news.ycombinator.com/item?id=6147478 https:/

by IanCal 13y ago

Then the parser might fail, and rightly so. A comment lower down shows it failing in a simple parser in go: https://news.ycombinator.com/item?id=6147478 https://news.ycombinator.com/item?id=6147478 Keys SHOULD be unique.

dnautics 13y ago
SHOULD != SHALL And, no, this scheme doesn't break the go parser because there isn't a typeshift between the "comment" fields, they are all strings. http://play.golang.org/p/bxcIIyAeph http://play.golang.org/p/bxcIIyAeph
- IanCal 13y ago
  Ah fair enough on the break, I was wrong there. But if the spec says that keys SHOULD be unique, what's the behaviour when they aren't?
  - dnautics 13y ago
    I would agree it's very hackey and probably not a good idea since the spec is liable to change. But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.
    - IanCal 13y ago
      > I would agree it's very hackey and probably not a good idea since the spec is liable to change Well it's not really about the spec changing, the spec doesn't have a defined behaviour for duplicate keys. > But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments. I don't think duplicate keys should be allowed, but I've no strong feelings on comments. I don't think there's any real need for them though.
      - dnautics 13y ago
        I'm biased, back in the BeOS -> Haiku days, I was wanting some sort of configuration textfile that would neatly be able to be parsed into a BArchive object (and presumably transmitted into a BMessage). XML was all the rage at the time, so I wrote for myself a sort of XML-ish format, but I never contributed it to the tree. I learned the problems with XMLs (should it be an attribute or an innerText?). I wanted something with a bracket notation, but JSON had not been discovered by crockford yet, if it had been I would have gotten more involved and tried to have it be adopted.

by IanCal 13y ago

dnautics 13y ago

SHOULD != SHALL And, no, this scheme doesn't break the go parser because there isn't a typeshift between the "comment" fields, they are all strings. http://play.golang.org/p/bxcIIyAeph http://play.golang.org/p/bxcIIyAeph

IanCal 13y ago
Ah fair enough on the break, I was wrong there. But if the spec says that keys SHOULD be unique, what's the behaviour when they aren't?
- dnautics 13y ago
  I would agree it's very hackey and probably not a good idea since the spec is liable to change. But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.
  - IanCal 13y ago
    > I would agree it's very hackey and probably not a good idea since the spec is liable to change Well it's not really about the spec changing, the spec doesn't have a defined behaviour for duplicate keys. > But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments. I don't think duplicate keys should be allowed, but I've no strong feelings on comments. I don't think there's any real need for them though.
    - dnautics 13y ago
      I'm biased, back in the BeOS -> Haiku days, I was wanting some sort of configuration textfile that would neatly be able to be parsed into a BArchive object (and presumably transmitted into a BMessage). XML was all the rage at the time, so I wrote for myself a sort of XML-ish format, but I never contributed it to the tree. I learned the problems with XMLs (should it be an attribute or an innerText?). I wanted something with a bracket notation, but JSON had not been discovered by crockford yet, if it had been I would have gotten more involved and tried to have it be adopted.