Gary Gregory wrote: > Thoughts on generics for Codec > > I tried an approach to add generics to Codec here: > https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics > > I consider this (now old) experiment part success and part failure and I > would like to share it here. > > I will call this experiment the ‘single type’ approach. In this experiment > I use one interface called Encoder<I,O> and one called Decoder<I,O> such > that one class can implement a Codec by implementing both Encoder and > Decoder. > > In the branch, the following interfaces support generics: > > · Decoder<I, O> > > · Encoder<I, O> > > The branch adds interfaces that respectively subclass each of the above: > > · SymmetricDecoder<T> extends Decoder<T, T> > > · SymmetricEncoder<T> extends Encoder<T, T> > > The following interfaces subclass their respective symmetric interfaces: > > · StringEncoder<String, String> > > · StringDecoder<String, String> > > · BinaryEncoder< byte[], byte[]> > > · BinaryDecoder< byte[], byte[]> > > The main problem with this approach is that -- because Java’s current > implementation of generics performs type erasure at compile time -- a > class can implement exactly one Encoder and one Decoder. In Codec 1, we > have many classes that cannot fit in such a scheme, because we encode and > decode to multiple types, like String and byte[]. This explains the > different sets of classes in this branch. > Class Changes > > *BinaryCodec* is now abstract and you must replace it with one of its > subclasses: *BinaryByteCodec* or *BinaryCharCodec*. Option: We could leave > this class concrete. > > *Hex* is now abstract and you must replace it with one of its subclasses: > * HexByteCodec* or *HexCharCodec*. Option: We could leave this class > concrete. > > *QuotedPrintableCodec* is now abstract and you must replace it with one of > its subclasses: *QuotedPrintableBinaryCodec* or > *QuotedPrintableCharCodec*. Option: We could leave this class concrete. > > *URLCodec* is now abstract and you must replace it with one of its > subclasses: *URLByteCodec* or *URLCharCodec*. Option: We could leave this > class concrete. > > The abstract class names are not prefixed with Abstract for less ugly code > that use static method. > > We should move these static methods to their proper subclasses, further > breaking compatibility. > Method Changes > > The Encoder and Decoder interfaces now implement generics. This means that > there no longer is encode and decode methods that take and return > *Objects*. Call sites must use the proper type, like *String*, *char[]*, > or *byte[]*. Next > > Upon reflection, it seems overly restrictive (thanks to Java) to have one > encoding or decoding type per class. What should be the alternative for a > nice OO design?
Isn't the StringEncoder/-Decoder in that case only a simple wrapper around the binary version? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
