Subj : Re: Changing Object.prototype.toSource to use double-quotes everywhere
To   : netscape.public.mozilla.jseng
From : Peter Wilson
Date : Fri May 13 2005 04:26 pm

zwetan wrote:
> (my first reflex was to answer by email, and then thinking of all that
> overnight my answer is a little different now)
 >
> [snip]
> 
>>I'm all in favor of simplifying things for me, though.  And the more I
>>think about it, since JS doesn't quote all property identifiers, we are
>>not JSON-compatible even if we double- rather than single-quote.  So now
>>I am wondering whether the better answer is not to output JSON via a new
>>option to toSource, or via a toJSONString method.
> 
> 
> imho a toJSONString is the way to go
> 
> JSON strings is a subset of what can be produced by toSource
> it does not support Date object, Function object, Error object...
> 
> simple exemple:
> myDat = new Date();
> myDat.toSource(); // (new Date(1115975725780))
> 
> how is a JSON string supposed to represent that
> if toSource was modified to be JSON compatible ?
>

I don't see why this should be part of ECMAscript at al. Given the 
simple encoding for JSON strings an almost trivial recusrive-descent 
JavaScript function generates the necessary format when required.

I don't like the idea of bloating the core SpiderMonkey engine with 
functions like this that will be used in a very minor number of cases.

I'm more likely to want toBase64string or toQuotedPrintableString - both 
of which I implemented in JavaScript - no need to add bloat.

Even assuming there is minimal code-blat, I use serialised JS objects a 
lot, and adding extra quotes where they are not necessary is again an 
un-necessary overhead.

If it were included I'd prefer it to be a compile time option, which is 
another reason for it not being in there.

Just my t'penny worth.

> 
>>JSON doesn't also handle cycles and join points, so if a JS object graph
>>that's not a tree is toSource'ed or toJSONString'ed, and the consumer
>>wants JSON, it will choke on the sharp variables.
>> 
> perharps I don't understand what you're meaning, but I can not think
> of any object structure that would not produce a tree graph ???
> 

In fact very many non-trivial data-structures are graphs rather than 
pure tree. Even take the case where I build a real tree, and have a 
'parent' reference - suddenly it's got a loop.

It's also not uncommon to have two properties reference the same object 
within a real-life data-structure.

> except perharps for a situation where people would want toJSONString'ed
> the Global Object doing something like (using JSDB for a quick test)
> 
> _global = this;
> toto = { a:1, b:2 };
> titi = { test:"hello", test2:"world" };
> println( _global.toJSONString() );
> 
> toJSONstring.js:79      InternalError: too much recursion
> 
> compared to:
> 
> _global = this;
> toto = { a:1, b:2 };
> titi = { test:"hello", test2:"world" };
> println( _global.toSource() );
> 
> #1={_global:#1#, toto:{a:1, b:2}, titi:{test:"hello", test2:"world"}}
> 
> this kind of case could be indeed handdled more elegantly
> with a toJSONString method implemented directly in spidermoneky
> instead of user provided methods.
> 
> 
>>Bcc'ing Doug Crockford for his thoughts.
>>
> 
> 
> I'm aware that we talk about spidermoneky here,
> but I'm also concerned to have JSON strings available in other
> ECMAScript implementation.
> 
Write a simple recursive JS function when you need this. It's not the 
job of the core libraries to provide every possible string format. I 
think it's a red-herring for this format because "it's a bit like 
js.toSource() formats".

> it can be a toJSONString method added or a toSource method modified in
> spidermonkey
> this does not change the fact that other implementations would also want to
> exchange
> JSON string in other "platforms", which is imho the goal of a data exchange
> format.
> 
> JSON is available for non-ECMAScript environment: Java, C#, PHP etc..
> but what the use of JSON if it can not work on other ECMAScript
> non-spidermonkey
> based environment, especially when those environments does not have in the
> first place
> a toSource method ?

Of course it can - simple function to decode it.

> 
> JSON is great, toSource is great
> but if toSource is modified to produce JSON strings
> other environments not having the toSource method and its introspection
> features
> (global object for one) would not be able to implement a fully compatible
> JSON
> serialization/deserialization mecanism,
> which imho is not good.
> 
>  [snip]

Pete
--
http://www.whitebeam.org
http://www.yellowhawk.co.uk
-------

.