Changing Object.prototype.toSource to use double-quotes everywhere
Brendan Eich
are not lexical identifiers, but Douglas Crockford proposed today at the
AJAX Summit that it use double-quotes, as that's more JSON-like (JSON
specifies that all property ids are quoted, but I don't think we should
do that at this stage, without more testing and web-spidering).
Just switching things so
var o = {foo: "bar", '$#@%': 42};
o.toSource()
results in a string containing {foo:"bar", "$#@%":42} instead of
{foo:"bar", '$#@%':42} is a small change that should be easy to adapt
to, if any existing consumers of toSource output have come to depend on
single quotes being used, if any quoting is used, around property ids.
Comments?
/be
zwetan
[snip]
>
> Just switching things so
>
> var o = {foo: "bar", '$#@%': 42};
> o.toSource()
>
> results in a string containing {foo:"bar", "$#@%":42} instead of
> {foo:"bar", '$#@%':42} is a small change that should be easy to adapt
> to, if any existing consumers of toSource output have come to depend on
> single quotes being used, if any quoting is used, around property ids.
>
> Comments?
>
would it not be more simpler to let users "override" the prototype method
at runtime with their own method instead of changing the code-base ?
zwetan
Brendan Eich
> hello,
Yes, it would be simpler for me. No, it would not be simpler for people
trying to produce JSON-compatible strings, because overriding toSource
is non-trivial.
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.
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.
Bcc'ing Doug Crockford for his thoughts.
/be
Peter Wilson
> (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.
>
>
>
> 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
-------
Peter Wilson
with this functionality. It's trivially easy to write a JS function to
do this for any arbitrary JS object structure as long as it's legally
capable of being represented as a JSON string.
Now if you'd like to implement toQuotedPrintable for me.........
> Bcc'ing Doug Crockford for his thoughts.
>
> /be
--
Peter Wilson
http://www.whitebeam.org
http://www.yellowhawk.co.uk
------------------------------------------------------------------------
--
Peter Wilson
T: 01707 891840
M: 07796 656566
http://www.yellowhawk.co.uk
<http://www.yellowhawk.co.uk>
------------------------------------------------------------------------
zwetan
"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.
>
> 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".
>
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
Brendan Eich
> Brenden
(Brendan.)
> - I'm not sure I see the argument for bloating the core engine
> with this functionality. It's trivially easy to write a JS function to
> do this for any arbitrary JS object structure as long as it's legally
> capable of being represented as a JSON string.
>
> Now if you'd like to implement toQuotedPrintable for me.........
You're quite right -- I wouldn't do it in the core C code. JS is
overdue for a standard library mechanism, and ECMA TG1 is working on
Edition 4. Some on the committee already have implementations and would
put the issue of binding standard packages to real files or assemblies
off to the embedding, not make it a standard -- but I think there needs
to be a default everyone can count on.
I will be working on that, and other JS2-ish things, over the summer.
/be
Brendan Eich
graphs (neither does JSON, but you wouldn't want a "Too much recursion"
error for the edge case).
Also, why not use === undefined and === null, rather than == "undefined"
and == "null" in Object.prototype.toJSONString? A JS string whose
characters are the sequence "undefined" should not be turned into the
undefined value when serialized via JSON, it seems to me.
/be
Brendan Eich
> Hi, your code is fine for trees, but it doesn't handle arbitrary object
> graphs (neither does JSON, but you wouldn't want a "Too much recursion"
> error for the edge case).
Sorry, I skimmed your post to fast and noticed only after replying that
you dealt with this.
> Also, why not use === undefined and === null, rather than == "undefined"
> and == "null" in Object.prototype.toJSONString? A JS string whose
> characters are the sequence "undefined" should not be turned into the
> undefined value when serialized via JSON, it seems to me.
Otherwise your code is fine, and I think the only task for us is to see
whether we can make a standard library, written in JS, available to all
JS implementations that want to track the standard.
That's what I meant in my other post about "standard library mechanism"
-- it's fine to embed JS (JScript, whatever) in a Java, .NET, or other
world and use that world's standard packages. But people writing
portable JS, esp. for a common interoperable platform like the browser
or Linux, want a set of standard packages that are named and work the
same everywhere.
JS has lacked this for too long, being in the browser, or in the shadow
of a larger system of reusable packages such as a JVM. Nothing wrong
with Rhino, mind you -- but something's missing from JS-the-language.
/be
zwetan
"Brendan Eich" <bre...@meer.net> wrote in message
news:4284D6E8...@meer.net...
> Brendan Eich wrote:
> > Hi, your code is fine for trees, but it doesn't handle arbitrary object
> > graphs (neither does JSON, but you wouldn't want a "Too much recursion"
> > error for the edge case).
>
> Sorry, I skimmed your post to fast and noticed only after replying that
> you dealt with this.
>
well I got a solution, but I'm not really happy with it
declaring a _global = this
having a ToSource global function which deal only with the global object
usefull to dump all what is delcared in global though
> > Also, why not use === undefined and === null, rather than == "undefined"
> > and == "null" in Object.prototype.toJSONString? A JS string whose
> > characters are the sequence "undefined" should not be turned into the
> > undefined value when serialized via JSON, it seems to me.
>
indeed that would be more concise, didn't see that, thanks :)
> Otherwise your code is fine, and I think the only task for us is to see
> whether we can make a standard library, written in JS, available to all
> JS implementations that want to track the standard.
>
I'm doing exactly that, targeting principally JavaScript / JScript /
ActionScript
following to the best I understand it ECMA-262 3rd ed
> That's what I meant in my other post about "standard library mechanism"
> -- it's fine to embed JS (JScript, whatever) in a Java, .NET, or other
> world and use that world's standard packages. But people writing
> portable JS, esp. for a common interoperable platform like the browser
> or Linux, want a set of standard packages that are named and work the
> same everywhere.
>
> JS has lacked this for too long, being in the browser, or in the shadow
> of a larger system of reusable packages such as a JVM. Nothing wrong
> with Rhino, mind you -- but something's missing from JS-the-language.
>
I totally agree with that
ECMAScript lack libraries, frameworks etc..
focused only on the language not on the environment/platform
for my part all started with a library I call "core2"
1st step, I aligned all the different implementations taking the smallest
common denominator
in my case ActionScript v1, no RegEx, almost no eval, no Error object or
throw/try/catch close etc..
if something is missing from ECMA-262 in one envrionment add it etc..
2nd step, augmenting those core objects to add utilitarian methods
String.prototype.startsWith / endsWith / indexOfAny / etc..
all that inspired by the .NET framework
that gives a small library reusable everywhere
in the same time I ported JUnit to ECMAScript in the same spirit
to test all that
after that I went to the serialization/deserialization mecanism
having toSource on one side and an ECMAScript parser made
in ECMAScript on the other side
I steped on a lot of problems doing all that,
I don't know what JS2 will bring
I experienced so far adapting ECMA-262 compliant code
to ActionScript v2 and JScript.NET
and really I feel a little bitter...
I just hope ECMA TG1 do not forgot all the strong point
of ECMA-262 and will allow developpers to still use that.
zwetan
zwetan
well, I code some code who can do as JSON but without the quote,
that means you can use toSource() to serialize and a small parser to
deserialize,
if this can be insteresting I can post some code.
zwetan
zwetan
I *got* some code...
sorry for the typo