Andrew Red wrote:
> ...
> 1. Date#toJSON returns a string, if evaluated, it won't become that
> same date again:
> I'd like to note that this unit test passes in IE and FF:
>       testDate: function() {with(this) {
>               var date = new Date();
>               assert((eval('new Date(' + (date - 0) + ')') - 0) == (date - 
> 0));
>       }},
> I'd like to propose this method instead of the current one:
> Date#toJSON = function() {
>   return '(new Date(' + (this - 0) + '))';
> };
JSON has no special provision for storing dates.  They should be stored 
as strings.  Douglas Crockford's implementations uses ISO format with 
UTC time components.

> 2. Also, Object.toJSON returns undefined if the argument is Element.
> However, it might return a script that re-creates the structure of
> their childern.(Like, using your ingenious DOM Bulider.)
What would a server do with the properties of a DOM Element?  There are 
loads of native JS objects that don't really have any value by 
themselves as JSON.  (e.g. window, Regexp objects, form objects, etc.)

> 3. Number.NaN is not null, it's Number.NaN. The string 'Number.NaN'
> evaluates to this type and instance of JS object. 'null' evaluates to
> null instead, it also loses the original type of the Number object.
NaN is not in the JSON specifications either.  Null is the closest 
representation to NaN.

Prototype's toJSON methods must play nice with server-side 
interpreters.  AFAIK, client-server communication is the main use case 
for JSON.  Also consider that JSON is not eval'ed unless the regex 
detects that there are no illegal tokens such as function calls that 
would open up a script to hacking.

Also see:

- Ken Snyder

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to