Subj : Re: Changing Object.prototype.toSource to use double-quotes everywhere
To   : netscape.public.mozilla.jseng
From : zwetan
Date : Fri May 13 2005 07:18 pm


"Peter Wilson" wrote in message:
[snip]
>
> 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.
>
[snip]
> 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".
>
[snip]

hey I say the same since the start

but my other points are

that ECMA-262 spec is slow to update,
spidermonkey with JavaScript can lead the way
and act as an "intermediary" spec.

for ex:
toSource, not ECMA-262, but usefull for debugging and serializing.

serialization/deserialization in ECMAScript is something
which need to be carefully done and which imho gonna be more
and more needed with all the hype of AJAX

any dev can come with its own way of doing it with more
or less "features", the problem with that it's that it fragments
something that should be done the same way for everyone.

Changing toSource to be JSON compatible, well I don't know
if it's good, I m not fan either of the quoted identifiers,
but if spidermonkey implemented a toJSONString
it would give to the JSON serialization format a boost to
be implemented elsewhere, which can be good for having
a kind of "standard" way to serialize JS objects.

But the contrary could be done too,
modify JSON to parse unquoted identifiers
and so not modify toSource and use its actual output
for JSON serialization, but in this case I think the parser
would take more than 3KB.

zwetan

.