- ... In this specific example, I might choose to do this because multiple Java types map to the same JSON type, and it could help me a lot with identifyingMessage 1 of 42 , Jan 3, 2006View SourceOn 1/3/06, Douglas Crockford <douglas@...> wrote:
>In this specific example, I might choose to do this because multiple Java
> > Huh? If I'm writing an encoder that takes a Java data structure and
> > it into JSON, it would make perfect sense to me to generate comments (in
> > development mode) that tell me what Java structure was being
> encoded. So,
> > for example, I might output "/* java.util.HashMap */" in my JSON
> > before I render the corresponding JSON object.
> Why would you do that?
types map to the same JSON type, and it could help me a lot with identifying
which part of my code is wrong if I know whether a particular JSON array
started life as a Java array or as a List, ArrayList, or whatever. If you
need other examples to be convinced, I'm sure I can come up with them. ;-)
This is in development mode, where I want all the help I can get in
to debug in.
What expectation do you have of the receiver?
Depends on how you define the receiver. Fundamentally, this is something
that's going to show up as a string, that I can then choose what to do with.
In production, I'll almost certainly just eval it and get on with things. In
development mode, I might want to display the JSON string in a debug window
before (or after) I eval it, where I can look at it and see if I got what I
was expecting. The comments are solely for me, the developer, and can and
should be ignored by everything else.
Why waste the bandwidth?
I don't give a rat's ass about bandwidth at development time. I want to get
my job done as quickly and as easily as I can. I'm not going to use comments
What, specifically, is the value?
My time. Developer time is the most valuable and the scarcest resource in
software development. Anything that can help reduce the time it takes to
complete a working product is exceptionally valuable.
IMHO, to exclude comments from JSON on the basis that someone _might_ encode
something insidious in them, or _might_ slow down _their_ app by using them
in production, just doesn't jibe with the possibility that they can save
developer time and speed products to market.
Yahoo! Groups Links
>[Non-text portions of this message have been removed]
more in the LISP camp than the C camp , i.e., designed for expressive
power rather than bit-munging.
Programmers spend half their time looking at code. Ergonomics matter.
If line speed is a premium, why allow insignificant whitespace at all?
If line speed was a premium (and human consumption irrelevant), I'd be
using ASN.1 anyway; it is well established in the telecom world, and
there are tons of software and utilities that will help you with the
Think of comments as something that belong to a separate namespace. The
JSON parser should have no other business with comments than ignoring
them. If ECMAScript syntax for comments is too loose for easy parsing,
The alternative is an informal standard for comment properties that in
effect turns me into a carbon-based compiler and requires applications
to share a notation for comments anyway.
Atif Aziz wrote:
>>I think the real crux...
> As I said, I have a sneaking hunch that the real issue stems from tying
> JSON to YAML. With the comments debate generating some traffic, I feel
> less daring at this point to open up the disappearing of single-quoted
> strings gone as well as unquoted member names (at least on the decoding
> end). I am hoping Douglas will provide some insight so everyone can
> build a better understanding of the decisions that lead to several
> cutbacks in the specs. I think focusing the discussion too much on
> comments is really just avoiding a more fundamental issue. Does anyone
> agree or am I just rambling here?
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of
> Sent: Tuesday, January 03, 2006 8:03 PM
> To: email@example.com
> Subject: Re: [json] Re: Comments
> I think the real crux of this is simply, you cannot create a json
> format string through encoding from existing data that would contain
> comments (IIRC). It is only from people creating a json format string
> by hand.
> It is a fairly weak argument that the standard should support
> something that is not going to be used by the majority of people and
> probably not in production, from an early version of the standard,
> especially given that there are other ways get the same information
> across using the current standard.
> If you want to block out sections of json for ease of testing, then
> comment out the properties of the objects you are encoding, not /**/
> in some hand edited string.
> If you want to include comments about an object, include it in a
> property of the object.
> If you feel a need to include very detailed breakdowns, write a spec
> for the object your passing, it shouldn't be in the data stream.
> Your suggestion on wording is really avoiding the issue of why it
> should remain when there are other workable alternatives, and
> suggesting that it remain part of the standard just because it was
> once thought to be useful.
> Yahoo! Groups Links
> Yahoo! Groups Links