On Tue, Aug 16, 2011 at 11:14 PM, sebb <seb...@gmail.com> wrote: > On 17 August 2011 01:49, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Aug 16, 2011, at 19:40, sebb <seb...@gmail.com> wrote: > > > >> On 17 August 2011 00:20, Gary Gregory <garydgreg...@gmail.com> wrote: > >>> On Aug 16, 2011, at 18:01, sebb <seb...@gmail.com> wrote: > >>> > >>>> On 16 August 2011 22:53, Gary Gregory <garydgreg...@gmail.com> wrote: > >>>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies < > juliusdav...@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-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
