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

Comments in JSON

fadefade.com

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Comments in JSON

#161

Post by nonchalance »

greenlakejake wrote: post #151
nonchalance wrote: post #93

Earlier quoted context omitted.

> and JSON is code JSON is data. It appears to be JS code, but JSON is data. Data is not code ( http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing ). That's why the idea of data holding parsing directives is silly. If you want to do that, then embed that in the data (hold a MsgType key in the data records). There's no need for comments unless you are trying to use it for something other than raw data.

"Data is not code" Lisp programmers disagree.

Lisp programmers think "Code is data", not "Data is code"

Re: Comments in JSON

#162

Post by bzbarsky »

CanSpice wrote: post #142

Given the RFC says "The names within an object SHOULD be unique", there's nothing stopping me from writing a parser that takes the first name/value pair and throwing all the others on the floor. Or even better, picks a random name/value pair when the same name appears. Both of these behaviours are allowed by the RFC, and would break this hack. Putting comments into JSON in this way is a hack and shouldn't be used by…

Assuming you mean RFC 4627, you're quoting the restrictions on what character streams can be called "JSON". The "should" means that if your names are not unique you can still call it "JSON", but you should think twice about it.

The parsing behavior for JSON is not defined at all in RFC 4627, actually. Browsers (and Node, since it's using a browser js engine) use the parsing specification in ECMA-262 edition 5 section 15.12.2.

Note that ES5 section 15.12 in general is much stricter than RFC 4627, as it explicitly points out if you read it.

Re: Comments in JSON

#163

Post by bzbarsky »

IanCal wrote: post #18
nonchalance wrote: post #5

The JSON RFC ( http://www.ietf.org/rfc/rfc4627.txt?number=4627 ) says The names within an object SHOULD be unique. SHOULD is defined ( http://www.ietf.org/rfc/rfc2119 ) as 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different cou…

> Salient point is that you would need to ensure that you are only using JSON parsers that tolerate duplicate names (and use the last value) To drive this home a bit more forcefully, it requires knowing the behaviour of your parser where it is marked as "undefined" in the spec. If that isn't enough to stop you, DON'T USE JSON. A patch level change in a library could break your code in a non-obvious way and it would b…

Note that if your parser is the ES-standard JSON.parse, then the behavior here is in fact defined by ES5 section 15.12.2, even with duplicate names.

Re: Comments in JSON

#164

Post by defen »

TeMPOraL wrote: post #160
defen wrote: post #153

Earlier quoted context omitted.

Yes, I understand that "code is data". This does not mean that data, in general, is code; unless you are willing to make the words completely meaningless. "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Here is a string: "the quick brown fox jumps over the lazy dog". Or how about "\u0000\u0000". That is not code, as generally understood.

> "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Arbitrary data don't exist without some notion of an execution (or interpretation) platform. We tend to use "code" as a word for "commands telling some execution process what to do" and "data" as a word for "information that is meant to be transformed" but in reality this distinction is meaningless; both are f…

I understand all this. Like many people, I've written programs in C++ templates. But I think we're talking past each other because you want to make a pedantic point. I'm using the words as they are generally understood, not in a technical computer science way. I'm talking about first-level stuff, not metaprogramming. Let me give you some questions to ponder:

- Is the text of Hamlet code?

- Was it code as soon as Shakespeare wrote it?

- If not, did it become code once the electronic computer was invented? Or did that happen once a version was stored in a way accessible to an electronic computer?

- Did all the existing paper copies immediately become code at that point as well?

Re: Comments in JSON

#165

Post by dnautics »

IanCal wrote: post #157
dnautics wrote: post #148

Earlier quoted context omitted.

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

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?

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.

Re: Comments in JSON

#166

Post by serichsen »

CanSpice wrote: post #142

Given the RFC says "The names within an object SHOULD be unique", there's nothing stopping me from writing a parser that takes the first name/value pair and throwing all the others on the floor. Or even better, picks a random name/value pair when the same name appears. Both of these behaviours are allowed by the RFC, and would break this hack. Putting comments into JSON in this way is a hack and shouldn't be used by…

At least in ECMA-262 5, Ch. 15.12.2, there is a NOTE: "In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten."

It still does not feel right.

Re: Comments in JSON

#167

Post by dragonwriter »

defen wrote: post #164
TeMPOraL wrote: post #160

Earlier quoted context omitted.

> "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Arbitrary data don't exist without some notion of an execution (or interpretation) platform. We tend to use "code" as a word for "commands telling some execution process what to do" and "data" as a word for "information that is meant to be transformed" but in reality this distinction is meaningless; both are f…

I understand all this. Like many people, I've written programs in C++ templates. But I think we're talking past each other because you want to make a pedantic point. I'm using the words as they are generally understood, not in a technical computer science way. I'm talking about first-level stuff, not metaprogramming. Let me give you some questions to ponder: - Is the text of Hamlet code? - Was it code as soon as Shak…

> Is the text of Hamlet code?

> Was it code as soon as Shakespeare wrote it?

Yes, the text of a play is code meant to be executed by humans.

Re: Comments in JSON

#168

Post by defen »

dragonwriter wrote: post #167
defen wrote: post #164

Earlier quoted context omitted.

I understand all this. Like many people, I've written programs in C++ templates. But I think we're talking past each other because you want to make a pedantic point. I'm using the words as they are generally understood, not in a technical computer science way. I'm talking about first-level stuff, not metaprogramming. Let me give you some questions to ponder: - Is the text of Hamlet code? - Was it code as soon as Shak…

> Is the text of Hamlet code? > Was it code as soon as Shakespeare wrote it? Yes, the text of a play is code meant to be executed by humans.

That is pretty funny, but not what I was going for :)

Re: Comments in JSON

#170

Post by nonchalance »

lispm wrote: post #169
nonchalance wrote: post #161

Earlier quoted context omitted.

Lisp programmers think "Code is data", not "Data is code"

Lisp programmers write code so that data is code.

Lisp: "All code is data"

That's not the question. "All data is code" is not the same statement.

In a different context: "All apples are fruit" may be true but that doesn't imply "all fruit are apples"

Post reply on HN