Loading ...
Sorry, an error occurred while loading the content.

172RE: [json] Re: Comments

Expand Messages
  • Atif Aziz
    Jan 3 10:32 AM
      Jim has said it sweetly what pretty much everyone has been saying on
      this thread (perhaps just in too many words). He's also hit my points
      right on.

      If comments are not mentioned in the JSON specification, a parser might
      reasonably decline to parse the code at all.

      This is really the heart of the problem and I think it's just been
      proven as we discuss. The latest version of JSON.js over at
      http://www.crockford.com/JSON/json.js does not parse and ignore
      comments. As per message 157 [1], the parse function now uses a regular
      expression to check for a safe character stream, which does not take
      comments into consideration. Consequently, this...


      ...does not return the array [1,4] because the commented portion is
      considered unsafe or just not JSON.

      It's also shame that the previous version of JSON.js was not archived
      (luckily I have a copy on disk) or that the newer parse function was not
      added in a more compatible way.


      [1] http://groups.yahoo.com/group/json/message/157

      -----Original Message-----
      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
      Jim Washington
      Sent: Tuesday, January 03, 2006 7:00 PM
      To: json@yahoogroups.com
      Subject: Re: [json] Re: Comments

      Douglas Crockford wrote:

      >>I don't want to fight too hard on this subject and I hope my
      >>are not being misunderstood. It's hard to encourage decoders to
      >>recognize and ignore comments when a future implementation will base
      >>itself on the contents of what's written presently at
      >>http://www.json.org Otherwise it's JSON with comments, but not pure
      >>legal JSON and who wants two camps there? In most cases, however, a
      >>implementation will certainly start from one of the now many JSON
      >>bindings than go from scratch. Chances are then that most of them will
      >>include support for comments (at least on the parsing end). It worries
      >>me when I read things on the net along the lines of, "Yeah, some old
      >>JSON parsers support C-style comments."
      >I would like to understand your intentions. Where commentary is
      >important, it can be encoded directly in JSON, where the outermost
      >object resembles a COBOL IDENTIFICATION DIVISION.
      >Why specifically do you feel the need for C-style comments?
      It can be useful to comment-out sections of hand-coded JSON for
      development/testing, and to have inline human-readable comments about
      what is going on. A JSON parser should know to simply ignore these. If

      comments are not mentioned in the JSON specification, a parser might
      reasonably decline to parse the code at all.

      Perhaps a note in the specification to allow this would suffice,
      something like: Single-line and multi-line comments as defined in
      ECMA-262 may be used in JSON. Contents of comments shall be ignored by
      JSON parsers.

      -Jim Washington

      Yahoo! Groups Links
    • Show all 42 messages in this topic