[Moo] Native JSON encoding and decoding.

[Garret Wilson]

I'm happy to see that MooTools has JSON processing support---now I
won't have to maintain my own version which I created five years ago.
I was also excited to discover (I've been away from web programming
for a while) that many browsers nowadays provide native JSON
capabilities:

http://stackoverflow.com/questions/891299/browser-native-json-support-window-json

I assumed that the MooTools JSON version would delegate to the native
browser version if present. I looked at the code; apparently MooTools
at least checks to see if the browser already has a JSON object, but
then it goes and adds its own encode() and decode() methods() without
delegating to the native parse()/stringify()/whatever() methods of the
browser.

That's disappointing. Am I missing something, or does MooTools lack
JQuery's ability to use the browser's native JSON processing
capabilities if present?

[Philip Thompson]

On Feb 12, 2011, at 12:25 PM, Garret Wilson wrote:

I'm happy to see that MooTools has JSON processing support---now I
won't have to maintain my own version which I created five years ago.
I was also excited to discover (I've been away from web programming
for a while) that many browsers nowadays provide native JSON
capabilities:

http://stackoverflow.com/questions/891299/browser-native-json-support-window-json

I assumed that the MooTools JSON version would delegate to the native
browser version if present. I looked at the code; apparently MooTools
at least checks to see if the browser already has a JSON object, but
then it goes and adds its own encode() and decode() methods() without
delegating to the native parse()/stringify()/whatever() methods of the
browser.

That's disappointing. Am I missing something, or does MooTools lack
JQuery's ability to use the browser's native JSON processing
capabilities if present?

I agree that MT should probably handle it for you, but the beauty is that you can implement it yourself. Maybe something like......

if (this.JSON) {

    Object.append(JSON, {

        encode: function (obj) {

            return this.JSON.stringify(obj);

        },

        decode: function (string, secure) {

            return this.JSON.parse(string);

        }

    });

}

I've not done any testing, but seems like something similar should work. Happy coding.

~Philip

http://lonestarlightandsound.com/

[Garret Wilson]

I already had my on JSON code that was working fine. I thought it
would be of benefit to switch to MooTools because it is actively
maintained. I'm seeing that this is not the case. In fact, the request
(that was accepted!) ages ago for MooTools to throw an exception
instead of returning null on a JSON error hasn't made it to a release,
yet.

If I'm going to have to add stuff, I think it will be easier just to
bring back my own JSON code and add stuff to that.

Thanks anyway.

Garret

[anutron]

That was simply an error. It was added ages ago but somehow got lost in a merge or something. This is atypical. When we make changes to MooTools Core and push it to trunk, it is not likely to disappear.

MooTools is actively maintained. The JSON implementation present in MooTools 1.3 is full features and fully functional.

On Tue, Feb 15, 2011 at 7:12 AM, Garret Wilson <[hidden email]> wrote:

I already had my on JSON code that was working fine. I thought it
would be of benefit to switch to MooTools because it is actively
maintained. I'm seeing that this is not the case. In fact, the request
(that was accepted!) ages ago for MooTools to throw an exception
instead of returning null on a JSON error hasn't made it to a release,
yet.

If I'm going to have to add stuff, I think it will be easier just to
bring back my own JSON code and add stuff to that.

Thanks anyway.

Garret

[Peter Hewat]

Hi Aaron,

What is the reasoning behind not using the browsers native JSON if available?

Regards

[Jan Kassens]

Hi Peter,
MooTools had the JSON object before it was specified. This is the
reason the method names are different and the implementation of the
browser isn't used if present. As Aaron said, I think someone added
the support but it must have been lost somewhere.

This shouldn't be that big of a deal though, since the browsers that
have the JSON object all have quite fast JS engines and parsing a
typical JSON response should be a matter of a few millisecs. This
shouldn't be an excuse for not using the native functions, but you
probably wont have to worry about it (except if you want to send us a
pull request).

On Tue, Feb 15, 2011 at 5:34 PM, Peter Hewat <[hidden email]> wrote:
> Hi Aaron,
> What is the reasoning behind not using the browsers native JSON if
> available?
> Regards

[anutron]

Pull request:

https://github.com/mootools/mootools-core/pull/59

On Tue, Feb 15, 2011 at 11:01 AM, Jan Kassens <[hidden email]> wrote:

Hi Peter,
MooTools had the JSON object before it was specified. This is the
reason the method names are different and the implementation of the
browser isn't used if present. As Aaron said, I think someone added
the support but it must have been lost somewhere.

This shouldn't be that big of a deal though, since the browsers that
have the JSON object all have quite fast JS engines and parsing a
typical JSON response should be a matter of a few millisecs. This
shouldn't be an excuse for not using the native functions, but you
probably wont have to worry about it (except if you want to send us a
pull request).

On Tue, Feb 15, 2011 at 5:34 PM, Peter Hewat <[hidden email]> wrote:
> Hi Aaron,
> What is the reasoning behind not using the browsers native JSON if
> available?
> Regards

[Christoph Pojer]

Hello,

https://github.com/mootools/mootools-core/compare/17cf2d029a...b43547b036

will be in 1.3.1

[Jan Kassens]

The native JSON functions have additional arguments for a reviver
function. This arguments should probably be dropped by the MooTools
methods or implemented there. Currently, the additional argument is
only supported on some browsers.

On Tue, Feb 15, 2011 at 10:58 PM, Christoph Pojer
<[hidden email]> wrote:
> Hello,
> https://github.com/mootools/mootools-core/compare/17cf2d029a...b43547b036
>
> will be in 1.3.1

[Christoph Pojer]

done.

[Christoph Pojer]

or: fixed.

[Garret Wilson]

On Feb 15, 2:22 pm, Christoph Pojer <[hidden email]> wrote:
> or: fixed.

I'm impressed that this issue has been addressed so quickly.

I hate to be a complainer, but could I bring up one more thought?
Throughout my libraries, rather than creating a new API I try as
closely as possible to use the official API (e.g. W3C DOM) and, if one
browser's implementation is lacking, adding the appropriate API to
bring it up to the level of the official API. I had understood that
this is the spirit of MooTools, too.

I note that both IE and Firefox use JSON.parse() and JSON.stringify():

http://blogs.msdn.com/b/ie/archive/2008/09/10/native-json-in-ie8.aspx
http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/

That's not a standard, but it's as close as we're going to get at this
point. Wouldn't it be best to migrate developers towards an emerging
consensus and use the same method names? (Yes, "backwards-
compatibility", "MooTools' implementation was there first", etc. I
understand that.)

Best,

Garret

[Sean McArthur]

Personally, I think Crockford should be shot for creating "stringify" and "parse". It's "encode" and "decode" in other languages, and that's what I would prefer to use in JavaScript too.

On Tue, Feb 15, 2011 at 9:14 PM, Garret Wilson <[hidden email]> wrote:

On Feb 15, 2:22 pm, Christoph Pojer <[hidden email]> wrote:
> or: fixed.

I'm impressed that this issue has been addressed so quickly.

I hate to be a complainer, but could I bring up one more thought?
Throughout my libraries, rather than creating a new API I try as
closely as possible to use the official API (e.g. W3C DOM) and, if one
browser's implementation is lacking, adding the appropriate API to
bring it up to the level of the official API. I had understood that
this is the spirit of MooTools, too.

I note that both IE and Firefox use JSON.parse() and JSON.stringify():

http://blogs.msdn.com/b/ie/archive/2008/09/10/native-json-in-ie8.aspx
http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/

That's not a standard, but it's as close as we're going to get at this
point. Wouldn't it be best to migrate developers towards an emerging
consensus and use the same method names? (Yes, "backwards-
compatibility", "MooTools' implementation was there first", etc. I
understand that.)

Best,

Garret

[Steve Onnis]

I agree

 

Methods should mean something and reflect what they actually do, not be given names cause they sound cool or whatever. I mean what the frig is “stringify” ?

 

From: Sean McArthur [mailto:[hidden email]]
Sent: Wednesday, 16 February 2011 5:24 PM
To: [hidden email]
Subject: Re: [Moo] Re: Native JSON encoding and decoding.

 

Personally, I think Crockford should be shot for creating "stringify" and "parse". It's "encode" and "decode" in other languages, and that's what I would prefer to use in JavaScript too.

On Tue, Feb 15, 2011 at 9:14 PM, Garret Wilson <[hidden email]> wrote:

On Feb 15, 2:22 pm, Christoph Pojer <[hidden email]> wrote:
> or: fixed.

I'm impressed that this issue has been addressed so quickly.

I hate to be a complainer, but could I bring up one more thought?
Throughout my libraries, rather than creating a new API I try as
closely as possible to use the official API (e.g. W3C DOM) and, if one
browser's implementation is lacking, adding the appropriate API to
bring it up to the level of the official API. I had understood that
this is the spirit of MooTools, too.

I note that both IE and Firefox use JSON.parse() and JSON.stringify():

http://blogs.msdn.com/b/ie/archive/2008/09/10/native-json-in-ie8.aspx
http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/

That's not a standard, but it's as close as we're going to get at this
point. Wouldn't it be best to migrate developers towards an emerging
consensus and use the same method names? (Yes, "backwards-
compatibility", "MooTools' implementation was there first", etc. I
understand that.)

Best,

Garret

 

[Peter Hewat]

Whether you like those function names or not, they have become the de facto standard. I personally find those names pretty straight forwards but that is beside the point. Other scripts that don't necessarily use Mootools but use JSON use those names. It would be good if Mootools also added aliases to support stringify and parse. That way it would simplify integration.

Cheers,

Peter

[Christoph Pojer]

I'm impressed that this issue has been addressed so quickly.

Of course. At this point I'd like to say sorry. We (or I) simply forgot to put this to the 1.3 branch. Thanks for reminding.

 

I hate to be a complainer, but could I bring up one more thought?

Please bring up any thought you have.

 

I note that both IE and Firefox use JSON.parse() and JSON.stringify():

JSON.parse and JSON.stringify are indeed standards of ECMAScript 5. However, they both provide additional arguments which we do not want to support. See https://github.com/douglascrockford/JSON-js/blob/master/json2.js for more information. If you want to use standard compliant JSON methods in your code, use Doug's version. Our version is now basically a wrapper to the native functions and they cover what most people need. Therefore we won't support the standard in this case because it does not benefit us or our users much.

[Garret Wilson]

On Feb 16, 7:57 am, Christoph Pojer <[hidden email]> wrote:

> JSON.parse and JSON.stringify are indeed standards of ECMAScript 5. However,
> they both provide additional arguments which we do not want to support.

So we could throw an exception of one of these additional arguments
are passed in. What is important to me is that:

1. I use standard method calls.
2. My code uses native logic when available.
3. My code doesn't die when native logic is not available.

With proprietary MooTools methods, our use of JSON functionality is
limited in relation to ECMAScript 5. If on the other hand MooTools
were to use the same method names but throw exceptions for unsupported
functionality, JSON functionality would not be any less than the first
option---but we would be using standard method names, which is very
important to me.

Garret

[Arian Stolwijk]

If you really want to use JSON.stringify, just do:

if (!JSON.stringify) JSON.stringify = JSON.encode;

if (!JSON.parse) JSON.stringify = JSON.decode;

Furthermore I agree with Christoph.

On Wed, Feb 16, 2011 at 11:51 PM, Garret Wilson <[hidden email]> wrote:

On Feb 16, 7:57 am, Christoph Pojer <[hidden email]> wrote:

> JSON.parse and JSON.stringify are indeed standards of ECMAScript 5. However,
> they both provide additional arguments which we do not want to support.

So we could throw an exception of one of these additional arguments
are passed in. What is important to me is that:

1. I use standard method calls.
2. My code uses native logic when available.
3. My code doesn't die when native logic is not available.

With proprietary MooTools methods, our use of JSON functionality is
limited in relation to ECMAScript 5. If on the other hand MooTools
were to use the same method names but throw exceptions for unsupported
functionality, JSON functionality would not be any less than the first
option---but we would be using standard method names, which is very
important to me.

Garret

[Christoph Pojer]

I don't want to question you but why is it important to you to "call standard method names" if you are using a library anyway? I don't see the point in doing this. JSON.encode and JSON.decode is perfectly fine. Otherwise, do what arian proposed or load JSON2.js in your scripts :)

[Peter Hewat]

If you use another none Mootools aware script like Socket.IO-client
for example, it requires parse and stringify. Socket.IO-client
inculdes json.js in it's package. But in my case, I use Mootools so
including json.js is redundant. If Mootools had these aliases (cf.
Arian's code snippet) directly in it's core, you could remove json.js
and it would work out of the box (hence my "simplify integration"
comment). Adding json.js separably or manually adding this
compatibility layer goes against Mootools philosophy (light is right,
elegant cross-browser, etc.)

Cheers,
Peter

On Thu, Feb 17, 2011 at 00:51, Christoph Pojer
<[hidden email]> wrote:
> I don't want to question you but why is it important to you to "call
> standard method names" if you are using a library anyway? I don't see the
> point in doing this. JSON.encode and JSON.decode is perfectly fine.
> Otherwise, do what arian proposed or load JSON2.js in your scripts :)