JSON Methods?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JSON Methods?

Garrett Smith
I was wondering about the new JSON methods:

Object.prototype.toJSONString
String.prototype.parseJSON

to me, parseJSON seems like it should not be a String prototype method.

I'm thinking about other "parse" type of methods, like Date.parse( s );

Here, it's fairly obvious what parse should return -- A Date.

A parse method always parses a string, and in any well-designed API,
returns an object of the class it's bound to. We've already seen this
with Date.parse(), in other languages, like Java, there are
Integer.parseInt, Double.parseDouble.

It seems to me to make more sense to put parseJSON on object, but then
since JSON is a subset of Object, why not just put it as a subclass of
Object?

Object +
            |
            JSON

It seems to me, that Object.prototype.toJSONString could be also
implemented on a JSON instance.

JSON

constructor:
JSON( object )
static JSON parse( s ) throws SyntaxError
JSON.prototype.toString( )
JSON.prototype.isValid( )


Garrett

--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON Methods?

Lars T Hansen-2
On 9/2/07, Garrett Smith <[hidden email]> wrote:

> I was wondering about the new JSON methods:
>
> Object.prototype.toJSONString
> String.prototype.parseJSON
>
> to me, parseJSON seems like it should not be a String prototype method.
>
> I'm thinking about other "parse" type of methods, like Date.parse( s );
>
> Here, it's fairly obvious what parse should return -- A Date.

Date.parse() returns a number, not a Date.  E262-3 15.9.4.2 first paragraph.

--lars

> A parse method always parses a string, and in any well-designed API,
> returns an object of the class it's bound to. We've already seen this
> with Date.parse(), in other languages, like Java, there are
> Integer.parseInt, Double.parseDouble.
>
> It seems to me to make more sense to put parseJSON on object, but then
> since JSON is a subset of Object, why not just put it as a subclass of
> Object?
>
> Object +
>             |
>             JSON
>
> It seems to me, that Object.prototype.toJSONString could be also
> implemented on a JSON instance.
>
> JSON
>
> constructor:
> JSON( object )
> static JSON parse( s ) throws SyntaxError
> JSON.prototype.toString( )
> JSON.prototype.isValid( )
>
>
> Garrett
>
> --
> Programming is a collaborative art.
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: JSON Methods?

Garrett Smith
> > Well, at least it's not String.prototype.parseDate, that would make
> > even less sense, don't you agree?
>
> Sure, but only because we have a Date object.  We don't have a JSON
> object, because JSON is not a "thing".
>
Is that really true?
I think JSON is a definable thing.

JSON - JavaScript Object Notation.

"JSON is a data interchange format which is based on a safe subset of
JavaScript. JSON can represent simple or complex structured data. JSON
cannot represent functions or expressions. It is strictly data. It has
very specific rules of syntax, so it is very straightforward to
determine that a JSON text is syntactically correct. A JSON text can
easily be converted into a JavaScript value, which makes it a very
convenient format for use with JavaScript. There is support for use of
JSON with many other languages, including C#, Java, Perl, PHP, Python,
and Ruby. More information on JSON can be found at www.JSON.org."

FROM: http://www.json.org/JSONRequest.html

String.prototype.parseJSON, Object.prototype.toJSONString are already
in the draft, are they not?

So, I proposed a revision of those two methods in two different classes.

Some other considerations to having a cohesive JSON class:
pros:
 * one place where security issues can be managed (there will be more ;)
 * separate JSON object for developers to iterate over (vs for-in for
Object object)
 * doesn't add more methods to String or Object
 * one place to maintain the JSON source code (String, Object)
 * API documentation can be more easily unified (and read)

cons:
 * creates a new global symbol in the language

The definitions and discussion about JSON is here:
http://www.json.org/JSONRequest.html
http://www.json.org/
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss