undefined | Better HN

0 pointsdnautics12y ago0 comments

for that matter, just do:

{

  "comment":"this is a comment";
  "value": 45;

  "comment":"this is also a comment";
  "value2": 64;

  "comment":"we like overloading the comment field";
  "stringval":"but these stay the same";

}

0 comments

IanCal12y 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

Keys SHOULD be unique.

dnauticsOP12y 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

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

1 more reply

j / k navigate · click thread line to collapse

0 pointsdnautics12y ago0 comments

for that matter, just do:

{

  "comment":"this is a comment";
  "value": 45;

  "comment":"this is also a comment";
  "value2": 64;

  "comment":"we like overloading the comment field";
  "stringval":"but these stay the same";

}

0 comments

IanCal12y 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

Keys SHOULD be unique.

dnauticsOP12y 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

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

1 more reply

j / k navigate · click thread line to collapse