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