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

172RE: [json] Re: Comments

Expand Messages
  • Atif Aziz
    Jan 3, 2006
    • 0 Attachment
      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...

      JSON.parse("[1,/*2,3,*/4]")

      ...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.

      -Atif

      [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
      intentions
      >>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
      and
      >>legal JSON and who wants two camps there? In most cases, however, a
      new
      >>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