JSON Encoding

Bob Ippolito bob at redivi.com
Fri Oct 20 13:39:16 PDT 2006

On 10/20/06, Douglas Crockford <douglas at crockford.com> wrote:
> The current proposal provides a default decoding of dates as ISO strings. If you
> do not like that default, you can write your own toJSONString function and
> attach it either to your date object or to Date.prototype. This allows you to do
> anything you like. You can even generate non-JSON forms, although that is not
> recommended.

What is the purpose of toJSONString? In my experience it's a million
times more convenient to have a "toJSON" which allows you to perform
object substitution. This also ensures that the document *must* be
valid (if it is produced at all).

> One possible encoding is to emit your own date object along the lines of
>      {
>          "type": "Date",
>          "Date": ...what you like...
>      }
> You can then use the hook feature of parseJSON to turn such objects into dates.

That sucks though because you have to generate a whole new object
graph before encoding just to make this transformation.

> The filter function is intended to help honor protocol contracts, assuring that
> JavaScript's dynamic object behavior does not lead to accidental sending of
> unintended members to the server.

Bah. If you want to explicitly select members you would implement a
toJSON on the objects that should be restricted. Filtering of a whole
object graph full of a bunch of different things with no context
borders on ridiculous.


More information about the Es4-discuss mailing list