JSON package is entirely 'private', making inheritance impossible.

[GoogleCodeExporter]

It is impossible to (usefully) inherit/extend the JSON module because all the 
methods are 'private'.

Original issue reported on code.google.com by wole...@gmail.com on 2 Jul 2009 at 9:16

[GoogleCodeExporter]

Can you describe what you're interested in extending?  I'm hesitant to just 
generically move everything from 
private to protected.  

If I understood better what your end goals are, then I can determine which 
methods can be safely marked as 
protected while still keeping the integrity of the library.

Original comment by darron.schall on 8 Jul 2009 at 3:08

• Added labels: json

[GoogleCodeExporter]

I want to extend the encoder/decoder and teach it how to serialize my custom 
classes (for example, so it will 
encode dates in a particular format).

I'm curious, though, what you mean by "keeping the integrity of the library". 
What do you think would happen if 
methods were protected instead of private?

Original comment by wole...@gmail.com on 8 Jul 2009 at 7:28

[GoogleCodeExporter]

I think, in this case, it would be better to add hooks that you can extend for 
these particular areas.

For example, in JSONEncoder the convertToString() private method is a good one 
to mark as protected.  You 
can extend this with code like:

if ( value is Date )
{
    return customDateEncoder( value );
}
else
{
   return super. convertToString( value );
}

However, a more complicated method such as objectToString shouldn't necessarily 
be easily extendable 
because there are no places to really change the behavior with a subclass.  
JSON objects have to be encoded 
in a certain way, and trying to override this method would be difficult.  You 
would essentially have to just "roll 
you own" anyway.  

Making convertToString() protected would enable this approach since you can 
decide in there whether or not 
you want default functionality.

That's what I mean when I say "keeping the integrity of the library".  I think 
it's better to expose custom object 
serialize/deserialize hooks rather than generically make the guts of the 
library protected.  The library is 
designed around JSON syntax, so the extension points are really minimal here.

Unforunately, the way the class is designed, it's hard to "swap out" which 
encoder/decoder you want to use 
because these are not parameterized in the static methods.  In the process of 
updating the library to support 
this, it probably makes sense to add a parameter for encoderClass to 
JSON.encode that defaults to the current 
JSONEncoder so you can more easily swap out your own implementation should you 
want custom 
serialization.. something like:

public static function encode( o:Object, encoderClass:IJSONEncoder = null 
):String

Let me think about this some more.  It warrants some discussion, and would 
probably be better discussed on 
the mailing list.

Original comment by darron.schall on 8 Jul 2009 at 8:16

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Agreed – convertToString would be a good place to allow overriding.

I think I understand what you mean by "keeping the integrity of the library"... 
And although I would argue that 
it's still not strictly necessary (that is, it's better to warn the programmer 
that it's a bad idea to poke around 
here, but still give them the option), I can also see some benefit to the added 
restriction. So I'll pipe down 
about that :)

And, yea – when I did my implementation, I ran into the same problem with the 
static methods. To get around 
it, I subclassed the JSON class... But that's not a great general – passing 
it as an argument does seem better.

Anyway, thanks for your work on this library – it's much appreciated.

Original comment by wole...@gmail.com on 9 Jul 2009 at 2:38