Hi Matthew, On Wed, Aug 17, 2011 at 8:44 AM, Matthew Pocock < turingatemyhams...@gmail.com> wrote:
> Hi, > > Before I start, I'd love to see a binary compatible codec release with the > Beider Morse code in, and for generics to be dealt with in a later release. > I think this is where we are going, see previous emails and threads. > What I'm not quite sure about is why introducing generics will necessarily > cause breaking changes. > I can break things depending on the new design... we'll have to all discuss. See the branch in SVN for my first cut. https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics > It seems to me that the Encoder/Decoder interfaces are screaming out to be > generified, Yes! :) > and the current sub-interfaces should be removed unless there's > a compelling reason for them e.g. if they add extra methods. It is no > hardship in your code to write Encoder<String, String> rather than > StringEncoder. I realise that in any one application it may be the case > that > they use only one family of encoders (e.g. String => String), but I don't > see why this means we should be introducing a Java interface explicitly for > this use case. > I had not thought about it that way and I do like the idea since there are no new methods there. If you look at the branch I have: interface Encoder<I,O> with "O encode(I)" and interface SymmerticEncoder<T> extends Encoder<T, T> interface StringEncoder extends SymmerticEncoder<String> I could see doing away with StringEncoder. This would hopelessly break compatibility but I like it because it uses generics in the most natural way IMO. > We could have StringEncoder extends Encoder<String, String> if we wished. > The problem with this is that not every Encoder<String, String> is a > StringEncoder. It isn't a type alias. By introducing an extra interface, > we're introducing an extra layer of contract. Right now StringEncoder does > introduce an extra contract - it provides an over-loaded encode method > specialised to String, and it is possible for implementations to do > different work in the two different methods. > > In the specific case of the BeiderMorse encoder, the natural sig is > Encoder<String, Set<String>>. I expect this is the case for some other > StringEncoder implementations that deal with phonetic encodings. Would we > then introduce yet another interface, FuzzyStringEncoder to capture this? > I hope not! > All seems a bit messy to me. > > Java does not allow you to implement the same interface with different > generic type arguments. So, you can't have Foo implements Encoder<Object, > Object>, Encoder<String, String>. Yep, that's the only problem I ran into when adding generics to the branch > Because of this, you can't provide > different behaviour for the two different cases. This is sort of what the > current situation requires. However, look at what javap says has been > generated in these scenarios. > AH, it looks like you decompiled the branch ;) Gary > > ## java > public interface Encoder<ENC, DEC> { > public ENC encode(DEC dec); > } > > ## javap > public interface Encoder{ > > public abstract java.lang.Object encode(java.lang.Object); > > } > > ## java > public interface StringEncoder extends Encoder<String, String> {} > > ## javap > public interface StringEncoder extends Encoder{ > > } > > ## java > public class IdE implements Encoder<String, String> { > public String encode(String in) { > return in; > } > } > > ## javap > > public class IdE extends java.lang.Object implements Encoder{ > public IdE(); > public java.lang.String encode(java.lang.String); > public java.lang.Object encode(java.lang.Object); > } > > ## java > public class IdSe implements StringEncoder { > public String encode(String in) { > return in; > } > } > > ## javap > public class IdSe extends java.lang.Object implements StringEncoder{ > > public IdSe(); > > public java.lang.String encode(java.lang.String); > > public java.lang.Object encode(java.lang.Object); > > } > > > ## java > public interface StringEncoder2 extends Encoder<String, String> { > @Override > public String encode(String in); > } > > ## javap > public interface StringEncoder2 extends Encoder{ > public abstract java.lang.String encode(java.lang.String); > } > > ## java > public class IdSe2 implements StringEncoder2 { > public String encode(String in) { > return in; > } > } > > ## javap > public class IdSe2 extends java.lang.Object implements StringEncoder2{ > public IdSe2(); > public java.lang.String encode(java.lang.String); > public java.lang.Object encode(java.lang.Object); > } > > So, I guess I'm wondering what the breaking changes are that definitely get > introduced by generification, and if there are a significant number that > can't be dealt with by a bit of judicious use of deprecation and deprecated > interfaces. > > Matthew > > On 17 August 2011 06:24, Gary Gregory <garydgreg...@gmail.com> wrote: > > > On Aug 16, 2011, at 23:47, sebb <seb...@gmail.com> wrote: > > > > > On 17 August 2011 04:30, Gary Gregory <garydgreg...@gmail.com> wrote: > > >> On Tue, Aug 16, 2011 at 11:14 PM, sebb <seb...@gmail.com> wrote: > > > > > > ... > > > > > >> FYI: > > >> > > >> What would need to be reversed out of trunk for a 1.6 binary > compatible > > with > > >> 1.5 is: > > >> > > >> [image: Error]Method 'public StringEncoderComparator()' has been > removed > > >> org.apache.commons.codec.StringEncoderComparatorpublic > > >> StringEncoderComparator()[image: Error]Method 'public boolean > > >> isArrayByteBase64(byte[])' has been removed > > >> org.apache.commons.codec.binary.Base64public boolean > > >> isArrayByteBase64(byte[])[image: Error]Class > > >> org.apache.commons.codec.language.Caverphone removed > > >> org.apache.commons.codec.language.Caverphone > > >> [image: Error]Method 'public int getMaxLength()' has been removed > > >> org.apache.commons.codec.language.Soundexpublic int > > getMaxLength()[image: > > >> Error]Method 'public void setMaxLength(int)' has been removed > > >> org.apache.commons.codec.language.Soundexpublic void > > setMaxLength(int)[image: > > >> Error]Field charset is now > > >> finalorg.apache.commons.codec.net.URLCodeccharset[image: > > >> Error]Method 'public java.lang.String getEncoding()' has been removed > > >> org.apache.commons.codec.net.URLCodecpublic java.lang.String > > getEncoding() > > > > > > DIfficult to read, but looks like the Clirr report I generated. > > > > Yep, that's what the build generates. > > > > Gary > > > > > > > >> Gary > > >> > > >>> > > >>>> Gary > > >>>> > > >>>>> > > >>>>>> Gary > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>>> Gary > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Here is one thought in favour of removing them, at least from > > >>> Base64: > > >>>>>>>>> sometimes I copy Base64.java into my own projects as a > > copy/paste. > > >>> I > > >>>>>>>>> change the namespace. Then I remove references to other parts > of > > >>>>>>>>> commons-codec that I am not bringing in, but that Base64.java > > refers > > >>>>>>>>> to (typically Encoder, Decoder, and EncoderException). The > > smaller > > >>> my > > >>>>>>>>> delta after the copy/paste, the easier it is for me copy the > > newest > > >>>>>>>>> version in the future to keep my fork up to date. > > >>>>>>>>> > > >>>>>>>>> I like doing this because it can make the difference between > > needing > > >>> a > > >>>>>>>>> jar dependency and having no dependencies at all in some of my > > other > > >>>>>>>>> work. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Of course I am pretty focused on Base64. I have never used the > > >>> soundex > > >>>>>>>>> stuff. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I'm torn. On the one hand, I suspect the Encoder/Decoder > > interfaces > > >>>>>>>>> have been mostly unused, and analyzing the Maven2 repository > > could > > >>>>>>>>> shed light on that. Removing the interfaces makes sense if > they > > are > > >>>>>>>>> not really used, but on the other hand, improving them, making > > them > > >>>>>>>>> actually useful, also makes sense. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> yours, > > >>>>>>>>> > > >>>>>>>>> Julius Davies > > >>>>>>>>> 604-222-3310 (Home) > > >>>>>>>>> > > >>>>>>>>> $ sudo apt-get install cowsay > > >>>>>>>>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n > > >>>>>>>>> http://juliusdavies.ca/cowsay/ > > >>>>>>>>> > > >>>>>>>>> > > >>> --------------------------------------------------------------------- > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Thank you, > > >>>>>>>> Gary > > >>>>>>>> > > >>>>>>>> http://garygregory.wordpress.com/ > > >>>>>>>> http://garygregory.com/ > > >>>>>>>> http://people.apache.org/~ggregory/ > > >>>>>>>> http://twitter.com/GaryGregory > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > --------------------------------------------------------------------- > > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>>>>> > > >>>>>> > > >>>>>> > > --------------------------------------------------------------------- > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > --------------------------------------------------------------------- > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>> > > >>>> > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>> > > >>> > > >> > > >> > > >> -- > > >> Thank you, > > >> Gary > > >> > > >> http://garygregory.wordpress.com/ > > >> http://garygregory.com/ > > >> http://people.apache.org/~ggregory/ > > >> http://twitter.com/GaryGregory > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > -- > Dr Matthew Pocock > Visitor, School of Computing Science, Newcastle University > mailto: turingatemyhams...@gmail.com > gchat: turingatemyhams...@gmail.com > msn: matthew_poc...@yahoo.co.uk > irc.freenode.net: drdozer > tel: (0191) 2566550 > mob: +447535664143 > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
