Es4-discuss Digest, Vol 2, Issue 7
brendan at mozilla.org
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 json.org.
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 crockford.com> wrote:
>>>> From: "Erik Arvidsson" <erik.arvidsson at gmail.com>
>>> 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 mozilla.org
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
More information about the Es4-discuss