Es4-discuss Digest, Vol 2, Issue 7

Brendan Eich brendan at
Fri Apr 13 11:24:15 PDT 2007

Let's get to the bottom of this quickly.

The current proposal is based on long-standing JS code from  
It delegates toJSONString, just as JS has always delegated toString,  
allowing objects to serialize themselves fully, erroneously, or  
however they please.

The counter-proposal avoids delegating serialization at all,  
consolidating it in native code for speed (modulo toJSON costs) and  
reliability. If an object or class wants to specialize serialization  
to filter certain enumerable properties, it has to implement toJSON  
and create/hashcons an object with just the right enumerable properties.

The prototype-based delegation in JS for toString has not been a  
source of bugs AFAIK, but toString results are not serialized to  
protocol peers who deserialize -- so who knows? It's not a critical  
issue. With JSON, it is. The inherently well-formed serialization of  
the counter-proposal is its selling point. So let's argue about that.


On Apr 12, 2007, at 12:31 PM, Erik Arvidsson wrote:

> See earlier thread.
> The problem is that allowing people to return a string (override
> toJsonString) will very fast lead to invalid JSON. I thought it was
> agreed upon that it was better to rely on toJson intead?
> On 4/12/07, Douglas Crockford <douglas at> wrote:
>>>> From: "Erik Arvidsson" <erik.arvidsson at>
>>> I'm starting to see more and more people using
>>> Doug's proposal which I
>>> thought we all decided was dangerous to use and that
>>> we came to the
>>> conclusion that toJSONString would only be used at
>>> the top level for
>>> the serialization (and that it would be read only)
>>> and then the
>>> serializer would check for toJSON on the objects in
>>> the object graph
>>> as it serialized it.
>> I don't understand. What is the danger? Who agreed to what?
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at
> -- 
> erik
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list