186Re: [json] Re: Comments
- Jan 3, 2006I do have to say, unless I've missed something big in the thread, the
only thing I see keeping comment support *out* of the new version is
As in "because, you might shoot yourself in the foot" or "because,
you don't need them" or "because, there are other ways to make
comments without, you know, making comments" (still wrapping my
noodle around that last one).
The regex change is trivial. Just put it in and secretly (or not so
secretly) roll your eyes at anyone who might abuse them in some
perverse way you didn't expect.
And who took away single quoted strings and unquoted member names?!
Hell yes, I'd like to see the reasoning for changes like that, too.
 Apologies if I've missed said information, I'm a newcomer to the
On Jan 3, 2006, at 4:50 PM, Atif Aziz wrote:
> > I think the real crux...
> As I said, I have a sneaking hunch that the real issue stems from
> 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
> 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: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
> Sent: Tuesday, January 03, 2006 8:03 PM
> To: firstname.lastname@example.org
> 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
> Visit your group "json" on the web.
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
"You like Chinese food." -- Actual fortune cookie I received once.
- << Previous post in topic Next post in topic >>