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

[darronschall]

Originally filed by wolever on 2009-07-02T21:16:57

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

[darronschall]

Updated by darron.schall on 2009-07-08T15:08:07

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.

Added label json

[darronschall]

Updated by wolever on 2009-07-08T19:28:44

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?

[darronschall]

Updated by darron.schall on 2009-07-08T20:16:09

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.

Added label Type-Enhancement

[darronschall]

Updated by wolever on 2009-07-09T14:38:56

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.