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


"Brendan Eich" <brendan@meer.net> wrote in message
news:4284D6E8.3020909@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

.