Subj : Re: Proper behavior of uneval(-0.0) ?
To   : Igor Bukanov <igor@fastmail.fm>
From : Brendan Eich <brendan@meer.net>
Date : Thu Nov 13 2003 10:51 am

Igor Bukanov wrote:

> Brendan Eich wrote:
> ...
>
>> See the attached patch, let me know what you think.
>
>
> Well, then I will make uneval(-0) in Rhino to produce -0.
>
> Yet another question about uneval. AFAICS in SM the following property 
> holds for most usages of uneval:
>
> uneval(x) == uneval(eval(uneval(x)))
>
> or at least uneval(x) gives string that is a syntactically correct JS 
> that tries its best to archive equality of eval(uneval(x)) with x.
>
> But it does not work for native functions as uneval(Math.sin) produces 
> function sin() {[native code]} which is not valid JS.
>
> So what is the real goal of uneval?


uneval is meant to extend toSource so that any type (object or 
primitive) can be decompiled to a string that, when eval'd, results in 
the original value.

With native functions, you can't write such a string, unless you simply 
refer to the native's name, and that name is unambiguous when eval'd.  
Natives are a hard case; objects with private data, or of a class other 
than one of those that can represent itself in a source string form, are 
another.  Suggestions?

/be

.