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? 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
