Fwd: Drop JSON from the language?

[Garrett Smith]

On 10/12/07, Robert Sayre <sayrer at gmail.com> wrote:
> I think this feature might be better to add as a library. I'm working
> on a patch for Mozilla that provides a native JSON implementation like
> so: |new JSON()|. I had been basing the API on Bob's python simplejson
> API, but it looks like Google Caja did something similar in JS, so I
> might go with their method and argument names instead. It's pretty
> much the same otherwise.
>
> <http://google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/safe-json.js>
>
> Note that Caja's implementation of JSON.serialize makes exactly the
> same changes that have been proposed (and greeted with silence)
> here...
>
>             For json.js, other objects can provide their own implementation
>             of toJSONString(), in which case JSON serialization relies
>             on these objects to return a correct JSON string. If an
>             object instead returns an unbalanced part of a JSON
>             string and another object returns a compensating
>             unbalanced string, then an outer toJSONString() can
>             produce quoting confusions that invite XSS-like
>             attacks. The primary purpose of safe-json.js is to
>             prevent such attacks.
>
Objects can also override hasOwnProperty

json = {
  hasOwnProperty : document.body.appendChild // 'object' in IE
  "<script src='http://hackrz.net"></script>
}

The current proposal is not well-designed.

Objects that need JSON Strigification should provide their own
toJSONString, and that it should be optional. The current proposal
makes it not optional.

Object.prototype.toJSONString complicates objects with responsibility
that they should not necessarily have. It will be easy to misuse. It
will conflate Object.prototype with implementation details possibly
leaking into places they shouldn't. Instead of keeping reduced access,
it maximizes access. It does not allow the functionality to be tested
and debugged independently.

An interface or a JSON object  (as you suggest) avoids these problems.

String.prototype.parseJSON returns an Object. This complicates String
with something that is not about String behavior. XXX.parse should
return an object of type XXX -- Date.parse returns a Number, which is
odd and should not be a shining example.

If these features go in the language, implementations and library
authors will be required to handle this method for all objects, of any
type, forever. The change will be permanent and non retractable.

This feature is not critical; it can be added at any time. The flip
side to that is that once added, it cannot be removed. ever.

Dropping JSON from ES4 is a smart idea. It can be added in 4.1. In the
meantime, I would like to see JSON support, something along the lines
of what you're working on, like Caja, implemented in the Host
environment (Mozilla, Webkit, Opera, IE -- yeah right...). Once the
wrinkles are ironed out, it can go in ES4.

Garrett

>
> --
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>


--
Programming is a collaborative art.


-- 
Programming is a collaborative art.