Hi,

Regarding your first and 3rd point, Prototype's JSON implementation is
based on RFC 4627 (http://www.ietf.org/rfc/rfc4627.txt?number=4627)
and maps Douglas Crockford's JS implementation (http://json.org/
json.js).

JSON is a language agnostic data exchange format which happens to be
easily evaluated in JS, there's absolutely no guarantee that
converting an object to JSON and evalutating it will yield back the
original object.You can read more about JSON here: http://json.org/

Regarding your 2nd point, Prototype is built so that you can implement
you're own Element#toJSON method depending on your own needs, see our
tutorial for more details: http://prototypejs.org/learn/json.

As this is not part of the specs and rather application specific, it
will stay like that too.

Hope this helps... and happy prototyping!

Tobie






On Sep 26, 12:20 am, Andrew Red <[EMAIL PROTECTED]> wrote:
> To explain the subject line, I believe, the concept of JSON strings
> should be described by the following formula:
>
> eval(obj.toJSON()) -> obj,
>
> i.e. toJSON methods should return such a string from an object that if
> evaluated, the result to be identical to that original object.
>
> I believe, this formula should be tested by unit tests everywhere the
> toJSON method is implemented.
>
> And this concept is many times violated in Prototype. Examples:
>
> 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) + '))';
>
> };
>
> 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.)
>
> 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.
>
> Would you see my point?
>
> Thank you!
>
> Best regards,
>
> Andrew Revinsky


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to