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