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