You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Julius Davies <ju...@gmail.com> on 2011/08/16 20:28:56 UTC
[codec] Encoder / Decoder interface
Hi,
What do people think of the Encoder / Decoder interface in
commons-codec? Do people use it?
I know in my own usage patterns of commons-codec, I always go straight
for the concrete class that I want, and I never make use of the
Encoder / Decoder interface.
I'm in grad school right now, and one of the things I'm doing is
analyzing every jar, zip, tar, and war in the Maven2 central
repository. I could take a look to try and find out how often jars
that depend on commons-codec inside Maven2 make use of the Encoder /
Decoder interfaces. Of course it doesn't tell us anything about
proprietary systems or other systems that are not in Maven2, but it is
a pretty big collection of Java these days, might be interesting.
--
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 16 August 2011 22:23, Julius Davies <ju...@gmail.com> wrote:
>> Please see the recent discussion on adding generics to [codec] where I
>> propose "<O> encode(<I>)"
>>
>> Gary
>>
>
> Hi, Gary!!!
>
> I thought of replying to that thread, but I thought it's kinda rude to
> hijack a thread like that.
>
> What would be the pros/cons of just typing "svn remove Encoder.java"
> and "svn remove Decoder.java"? What do people think?
>
>
> 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.
>
It would be really interesting to know which of the coded classes and
interfaces are being used currently.
>
>
>
> --
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
Hi Matthew,
On Wed, Aug 17, 2011 at 8:44 AM, Matthew Pocock <
turingatemyhamster@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 <ga...@gmail.com> wrote:
>
> > On Aug 16, 2011, at 23:47, sebb <se...@gmail.com> wrote:
> >
> > > On 17 August 2011 04:30, Gary Gregory <ga...@gmail.com> wrote:
> > >> On Tue, Aug 16, 2011 at 11:14 PM, sebb <se...@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-unsubscribe@commons.apache.org
> > >>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> > >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhamster@gmail.com
> gchat: turingatemyhamster@gmail.com
> msn: matthew_pocock@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
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 17 August 2011 13:58, Stephen Colebourne <sc...@joda.org> wrote:
> On 17 August 2011 13:44, Matthew Pocock <tu...@gmail.com> wrote:
>> 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.
>
> I prefer StringEncoder to Encoder<String, String>. Its shorter and clearer.
> Overall, I'd say focus users on the concrete versions like StringEncoder.
If StringEncoder is a non-generic interface it also makes it possible
to combine interfaces in classes, as is done currently.
Not sure this is possible with all-generic interfaces.
> On 16 August 2011 21:38, Gary Gregory <ga...@gmail.com> wrote:
>> I am not a fan of these interfaces because they are not typed, "Object
>> encode(Object)" is too vague now that Generics have been an option for
>> years.
>
> The Object encode(Object) approach is still valid if the primary use
> case of the interface is for frameworks. In a framework, objects are
> generally treated as of type Object, so the API is fine. User code
That's useful to know (I've not used frameworks)
> should use concrete versions.
+1
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Matthew Pocock <tu...@gmail.com>.
On 17 August 2011 13:58, Stephen Colebourne <sc...@joda.org> wrote:
> The Object encode(Object) approach is still valid if the primary use
> case of the interface is for frameworks. In a framework, objects are
> generally treated as of type Object, so the API is fine. User code
> should use concrete versions.
>
In the case of ENC encode(DEC), the framework sees Object encode(Object), as
this is the erased type. The framework is happy and Java code referring to
the Encoder interface (directly or indirectly) is type-safe (baring casts
which we can't do much about).
Matthew
>
> Stephen
>
> --
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhamster@gmail.com
gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
Hi All:
On Wed, Aug 17, 2011 at 8:58 AM, Stephen Colebourne <sc...@joda.org>wrote:
> On 17 August 2011 13:44, Matthew Pocock <tu...@gmail.com>
> wrote:
> > 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.
>
> I prefer StringEncoder to Encoder<String, String>. Its shorter and clearer.
>
What about SymmetricEncoder<String>?
[Leaving aside bin compat for this chat...]
I'm not sure I buy the argument for keeping StringEncoder in a generified
codec2/3.
For example, Strings are very common if not the most common kind of List but
there is no java.util.StringList and so on.
Overall, I'd say focus users on the concrete versions like StringEncoder.
>
> On 16 August 2011 21:38, Gary Gregory <ga...@gmail.com> wrote:
> > I am not a fan of these interfaces because they are not typed, "Object
> > encode(Object)" is too vague now that Generics have been an option for
> > years.
>
> The Object encode(Object) approach is still valid if the primary use
> case of the interface is for frameworks. In a framework, objects are
> generally treated as of type Object, so the API is fine. User code
> should use concrete versions.
>
With a generics codec, a f/w can still use Object, it has to downcast but
it is possible/ugly.
Cheers!
Gary
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Encoder / Decoder interface
Posted by Stephen Colebourne <sc...@joda.org>.
On 17 August 2011 13:44, Matthew Pocock <tu...@gmail.com> wrote:
> 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.
I prefer StringEncoder to Encoder<String, String>. Its shorter and clearer.
Overall, I'd say focus users on the concrete versions like StringEncoder.
On 16 August 2011 21:38, Gary Gregory <ga...@gmail.com> wrote:
> I am not a fan of these interfaces because they are not typed, "Object
> encode(Object)" is too vague now that Generics have been an option for
> years.
The Object encode(Object) approach is still valid if the primary use
case of the interface is for frameworks. In a framework, objects are
generally treated as of type Object, so the API is fine. User code
should use concrete versions.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Matthew Pocock <tu...@gmail.com>.
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 <ga...@gmail.com> wrote:
> On Aug 16, 2011, at 23:47, sebb <se...@gmail.com> wrote:
>
> > On 17 August 2011 04:30, Gary Gregory <ga...@gmail.com> wrote:
> >> On Tue, Aug 16, 2011 at 11:14 PM, sebb <se...@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-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhamster@gmail.com
gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 16, 2011, at 23:47, sebb <se...@gmail.com> wrote:
> On 17 August 2011 04:30, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Aug 16, 2011 at 11:14 PM, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 17 August 2011 04:30, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Aug 16, 2011 at 11:14 PM, sebb <se...@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.
> 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-unsubscribe@commons.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 16, 2011 at 11:14 PM, sebb <se...@gmail.com> wrote:
> On 17 August 2011 01:49, Gary Gregory <ga...@gmail.com> wrote:
> > On Aug 16, 2011, at 19:40, sebb <se...@gmail.com> wrote:
> >
> >> On 17 August 2011 00:20, Gary Gregory <ga...@gmail.com> wrote:
> >>> On Aug 16, 2011, at 18:01, sebb <se...@gmail.com> wrote:
> >>>
> >>>> On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
> >>>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <
> juliusdavies@gmail.com>wrote:
> >>>>>
> >>>>>>> Please see the recent discussion on adding generics to [codec]
> where I
> >>>>>>> propose "<O> encode(<I>)"
> >>>>>>>
> >>>>>>> Gary
> >>>>>>>
> >>>>>>
> >>>>>> Hi, Gary!!!
> >>>>>>
> >>>>>> I thought of replying to that thread, but I thought it's kinda rude
> to
> >>>>>> hijack a thread like that.
> >>>>>>
> >>>>>> What would be the pros/cons of just typing "svn remove Encoder.java"
> >>>>>> and "svn remove Decoder.java"? What do people think?
> >>>>>>
> >>>>>
> >>>>> That would break binary compatibility and require and package name
> change.
> >>>>
> >>>> Agreed.
> >>>>
> >>>>> According
> >>>>>
> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
> >>>>>
> >>>>> "The lucene/solr source seems not to reference StringEncoder. All
> references
> >>>>> go via Encoder. In
> org.apache.lucene.analysis.phonetic.PhoneticFilter, it
> >>>>> has the code:
> >>>>>
> >>>>> String value = termAtt.toString();
> >>>>> String phonetic = null;
> >>>>> try { String v = encoder.encode(value).toString(); if (v.length() > 0
> &&
> >>>>> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} //
> just use
> >>>>> the direct text
> >>>>>
> >>>>> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry
> map of
> >>>>> encoders listing the (known) StringEncoder instances but typed to
> Encoder."
> >>>>
> >>>> That's a pity.
> >>>>
> >>>> I think the best we can do whilst maintaining binary compat. is to
> >>>> deprecate Decoder/Encoder.
> >>>
> >>> Deprecate in favor of one of the sub-interfaces?
> >>
> >> Yes.
> >>
> >> We are trying to move to compile-time checking; having the deprecation
> >> warning would be a useful start.
> >> {and of course it can easily be reversed later if we find a need to
> >> support Object]
> >
> > If we deprecate in 1.6 what does that mean when we undeprecate it as a
> > generified interface?
> >
> > Is that ok?
>
> Deprecation is only a compiler warning.
>
> I doubt we'd need to do that; the point is that the change is
> reversible, so there's no risk in doing it.
>
Check.
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()
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-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 17 August 2011 01:49, Gary Gregory <ga...@gmail.com> wrote:
> On Aug 16, 2011, at 19:40, sebb <se...@gmail.com> wrote:
>
>> On 17 August 2011 00:20, Gary Gregory <ga...@gmail.com> wrote:
>>> On Aug 16, 2011, at 18:01, sebb <se...@gmail.com> wrote:
>>>
>>>> On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
>>>>>
>>>>>>> Please see the recent discussion on adding generics to [codec] where I
>>>>>>> propose "<O> encode(<I>)"
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>
>>>>>> Hi, Gary!!!
>>>>>>
>>>>>> I thought of replying to that thread, but I thought it's kinda rude to
>>>>>> hijack a thread like that.
>>>>>>
>>>>>> What would be the pros/cons of just typing "svn remove Encoder.java"
>>>>>> and "svn remove Decoder.java"? What do people think?
>>>>>>
>>>>>
>>>>> That would break binary compatibility and require and package name change.
>>>>
>>>> Agreed.
>>>>
>>>>> According
>>>>> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
>>>>>
>>>>> "The lucene/solr source seems not to reference StringEncoder. All references
>>>>> go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
>>>>> has the code:
>>>>>
>>>>> String value = termAtt.toString();
>>>>> String phonetic = null;
>>>>> try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
>>>>> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
>>>>> the direct text
>>>>>
>>>>> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
>>>>> encoders listing the (known) StringEncoder instances but typed to Encoder."
>>>>
>>>> That's a pity.
>>>>
>>>> I think the best we can do whilst maintaining binary compat. is to
>>>> deprecate Decoder/Encoder.
>>>
>>> Deprecate in favor of one of the sub-interfaces?
>>
>> Yes.
>>
>> We are trying to move to compile-time checking; having the deprecation
>> warning would be a useful start.
>> {and of course it can easily be reversed later if we find a need to
>> support Object]
>
> If we deprecate in 1.6 what does that mean when we undeprecate it as a
> generified interface?
>
> Is that ok?
Deprecation is only a compiler warning.
I doubt we'd need to do that; the point is that the change is
reversible, so there's no risk in doing it.
> 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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 16, 2011, at 19:40, sebb <se...@gmail.com> wrote:
> On 17 August 2011 00:20, Gary Gregory <ga...@gmail.com> wrote:
>> On Aug 16, 2011, at 18:01, sebb <se...@gmail.com> wrote:
>>
>>> On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
>>>>
>>>>>> Please see the recent discussion on adding generics to [codec] where I
>>>>>> propose "<O> encode(<I>)"
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>
>>>>> Hi, Gary!!!
>>>>>
>>>>> I thought of replying to that thread, but I thought it's kinda rude to
>>>>> hijack a thread like that.
>>>>>
>>>>> What would be the pros/cons of just typing "svn remove Encoder.java"
>>>>> and "svn remove Decoder.java"? What do people think?
>>>>>
>>>>
>>>> That would break binary compatibility and require and package name change.
>>>
>>> Agreed.
>>>
>>>> According
>>>> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
>>>>
>>>> "The lucene/solr source seems not to reference StringEncoder. All references
>>>> go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
>>>> has the code:
>>>>
>>>> String value = termAtt.toString();
>>>> String phonetic = null;
>>>> try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
>>>> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
>>>> the direct text
>>>>
>>>> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
>>>> encoders listing the (known) StringEncoder instances but typed to Encoder."
>>>
>>> That's a pity.
>>>
>>> I think the best we can do whilst maintaining binary compat. is to
>>> deprecate Decoder/Encoder.
>>
>> Deprecate in favor of one of the sub-interfaces?
>
> Yes.
>
> We are trying to move to compile-time checking; having the deprecation
> warning would be a useful start.
> {and of course it can easily be reversed later if we find a need to
> support Object]
If we deprecate in 1.6 what does that mean when we undeprecate it as a
generified interface?
Is that ok?
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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 17 August 2011 00:20, Gary Gregory <ga...@gmail.com> wrote:
> On Aug 16, 2011, at 18:01, sebb <se...@gmail.com> wrote:
>
>> On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
>>>
>>>>> Please see the recent discussion on adding generics to [codec] where I
>>>>> propose "<O> encode(<I>)"
>>>>>
>>>>> Gary
>>>>>
>>>>
>>>> Hi, Gary!!!
>>>>
>>>> I thought of replying to that thread, but I thought it's kinda rude to
>>>> hijack a thread like that.
>>>>
>>>> What would be the pros/cons of just typing "svn remove Encoder.java"
>>>> and "svn remove Decoder.java"? What do people think?
>>>>
>>>
>>> That would break binary compatibility and require and package name change.
>>
>> Agreed.
>>
>>> According
>>> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
>>>
>>> "The lucene/solr source seems not to reference StringEncoder. All references
>>> go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
>>> has the code:
>>>
>>> String value = termAtt.toString();
>>> String phonetic = null;
>>> try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
>>> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
>>> the direct text
>>>
>>> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
>>> encoders listing the (known) StringEncoder instances but typed to Encoder."
>>
>> That's a pity.
>>
>> I think the best we can do whilst maintaining binary compat. is to
>> deprecate Decoder/Encoder.
>
> Deprecate in favor of one of the sub-interfaces?
Yes.
We are trying to move to compile-time checking; having the deprecation
warning would be a useful start.
{and of course it can easily be reversed later if we find a need to
support Object]
> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 16, 2011, at 18:01, sebb <se...@gmail.com> wrote:
> On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
>>
>>>> Please see the recent discussion on adding generics to [codec] where I
>>>> propose "<O> encode(<I>)"
>>>>
>>>> Gary
>>>>
>>>
>>> Hi, Gary!!!
>>>
>>> I thought of replying to that thread, but I thought it's kinda rude to
>>> hijack a thread like that.
>>>
>>> What would be the pros/cons of just typing "svn remove Encoder.java"
>>> and "svn remove Decoder.java"? What do people think?
>>>
>>
>> That would break binary compatibility and require and package name change.
>
> Agreed.
>
>> According
>> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
>>
>> "The lucene/solr source seems not to reference StringEncoder. All references
>> go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
>> has the code:
>>
>> String value = termAtt.toString();
>> String phonetic = null;
>> try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
>> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
>> the direct text
>>
>> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
>> encoders listing the (known) StringEncoder instances but typed to Encoder."
>
> That's a pity.
>
> I think the best we can do whilst maintaining binary compat. is to
> deprecate Decoder/Encoder.
Deprecate in favor of one of the sub-interfaces?
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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by sebb <se...@gmail.com>.
On 16 August 2011 22:53, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
>
>> > Please see the recent discussion on adding generics to [codec] where I
>> > propose "<O> encode(<I>)"
>> >
>> > Gary
>> >
>>
>> Hi, Gary!!!
>>
>> I thought of replying to that thread, but I thought it's kinda rude to
>> hijack a thread like that.
>>
>> What would be the pros/cons of just typing "svn remove Encoder.java"
>> and "svn remove Decoder.java"? What do people think?
>>
>
> That would break binary compatibility and require and package name change.
Agreed.
> According
> https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
>
> "The lucene/solr source seems not to reference StringEncoder. All references
> go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
> has the code:
>
> String value = termAtt.toString();
> String phonetic = null;
> try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
> !value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
> the direct text
>
> In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
> encoders listing the (known) StringEncoder instances but typed to Encoder."
That's a pity.
I think the best we can do whilst maintaining binary compat. is to
deprecate Decoder/Encoder.
> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <ju...@gmail.com>wrote:
> > Please see the recent discussion on adding generics to [codec] where I
> > propose "<O> encode(<I>)"
> >
> > Gary
> >
>
> Hi, Gary!!!
>
> I thought of replying to that thread, but I thought it's kinda rude to
> hijack a thread like that.
>
> What would be the pros/cons of just typing "svn remove Encoder.java"
> and "svn remove Decoder.java"? What do people think?
>
That would break binary compatibility and require and package name change.
According
https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13083179&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083179
"The lucene/solr source seems not to reference StringEncoder. All references
go via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it
has the code:
String value = termAtt.toString();
String phonetic = null;
try { String v = encoder.encode(value).toString(); if (v.length() > 0 &&
!value.equals(v)) phonetic = v; } catch (Exception ignored) {} // just use
the direct text
In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
encoders listing the (known) StringEncoder instances but typed to Encoder."
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Encoder / Decoder interface
Posted by Julius Davies <ju...@gmail.com>.
> Please see the recent discussion on adding generics to [codec] where I
> propose "<O> encode(<I>)"
>
> Gary
>
Hi, Gary!!!
I thought of replying to that thread, but I thought it's kinda rude to
hijack a thread like that.
What would be the pros/cons of just typing "svn remove Encoder.java"
and "svn remove Decoder.java"? What do people think?
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Encoder / Decoder interface
Posted by Gary Gregory <ga...@gmail.com>.
Hi Julius!
I am not a fan of these interfaces because they are not typed, "Object
encode(Object)" is too vague now that Generics have been an option for
years.
The interfaces are a good idea if you want to process the same data with
similar but different codecs and use the same code. So there is value there.
Please see the recent discussion on adding generics to [codec] where I
propose "<O> encode(<I>)"
Gary
On Tue, Aug 16, 2011 at 2:28 PM, Julius Davies <ju...@gmail.com>wrote:
> Hi,
>
> What do people think of the Encoder / Decoder interface in
> commons-codec? Do people use it?
>
> I know in my own usage patterns of commons-codec, I always go straight
> for the concrete class that I want, and I never make use of the
> Encoder / Decoder interface.
>
>
> I'm in grad school right now, and one of the things I'm doing is
> analyzing every jar, zip, tar, and war in the Maven2 central
> repository. I could take a look to try and find out how often jars
> that depend on commons-codec inside Maven2 make use of the Encoder /
> Decoder interfaces. Of course it doesn't tell us anything about
> proprietary systems or other systems that are not in Maven2, but it is
> a pretty big collection of Java these days, might be interesting.
>
>
>
> --
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory