commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [codec] Encoder / Decoder interface
Date Wed, 17 Aug 2011 00:49:20 GMT
On Aug 16, 2011, at 19:40, sebb <sebbaz@gmail.com> wrote:

> On 17 August 2011 00:20, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Aug 16, 2011, at 18:01, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 16 August 2011 22:53, Gary Gregory <garydgregory@gmail.com> wrote:
>>>> On Tue, Aug 16, 2011 at 5:23 PM, Julius Davies <juliusdavies@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message