JSON decoding

Bob Ippolito bob at redivi.com
Fri Nov 3 07:14:09 PST 2006

On 11/3/06, P T Withington <ptw at pobox.com> wrote:
> I think we have this upside down.  We're worried about the user
> creating an invalid JSON string.  Why?  Because they could break the
> reader?  Doesn't the reader have to protect itself?  (Perhaps the
> lure of eval as a reader has confused us.)

The proposal definitely doesn't use eval as a reader.

> It seems more important to tell the user:  'You tried to create a
> JSON representation of something, but it can't be represented in a
> way that parseJSON can meaningfully reconstruct it".

The problem is injection attacks and intermittent brokenness based on
input values.

>  From an historical point of view, perhaps we are trying to do too
> much with JSON.
> JSON reminds me of Lisp's print/read, which eventually evolved a flag
> [*print-readably*](http://www.lisp.org/HyperSpec/Body/var_stprint-
> readablyst.html#STprint-readablyST).  If true, you will get an error
> if you try to print an object that cannot be represented in a way
> that read can parse and construct a 'similar' object.  Print/read
> relies, as does JSON, on the implicit type-encoding of the language
> literals.
> toJSON seems like 'half a loaf'.  It lets me encode an arbitrary
> object, but without a corresponding fromJSON, what use is it?

The whole load is there, just not in this particular implementation.
The object of current discussion was encoding, not decoding, so I
didn't implement a whole parser.

(from Brendan's email on the 20th)

    * String.prototype.parseJSON( hook )

Returns the value represented by the string. A syntaxError is thrown
if the string was not a strict JSON text.

The optional hook function will be called for each object value
found. It is passed each object. Its return value will be used
instead of the object in the final structure.


More information about the Es4-discuss mailing list