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.
What I'm not quite sure about is why introducing generics will necessarily
cause breaking changes.
It seems to me that the Encoder/Decoder interfaces are screaming out to be
generified, 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.
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?
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>. 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.
## 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
