commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@joda.org>
Subject Re: [codec] getting the bmpm code out there
Date Fri, 12 Aug 2011 07:37:11 GMT
I've just noticed this thread.

I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.

- Changing to JDK 5 does not require a a package name change (generics
are backward compatible if the erased signatures don't change).
- Removing deprecated methods does not require a package name change
(and potentially, we should just leave them in)
- It is far far more user friendly to not have a "new" codec and an
"old" codec in their path.

Looking back at [lang], I think that a different focus might have
allowed 90% of the code to have been compatible and in the same
package, with 10% in a new package. [codec] might well fit that model
too.

For example, if a method needs its signature changing, create a new
method alongside and deprecate the original. Yes, it isn't as pretty,
but it is generally better for users. Only if there are too many cases
like this to keep the API sane, should a "new" codec (or any other
commons lib) be created.

Stephen


On 11 August 2011 23:44, Gary Gregory <garydgregory@gmail.com> wrote:
> On Thu, Aug 11, 2011 at 4:10 PM, sebb <sebbaz@gmail.com> wrote:
>> On 11 August 2011 20:56, Gary Gregory <garydgregory@gmail.com> wrote:
>>> Hello All!
>>>
>>> Topic 1: Housekeeping: package name and POM.
>>>
>>> The next codec release out of trunk will be major release labeled 2.0,
>>> the current release is 1.5.
>>>
>>> In trunk, I've removed deprecated methods and the project now requires
>>> Java 5. This means 2.0 will not be a drop-in binary compatible release
>>> for 1.5.
>>>
>>> I'd like to confirm or deny that this means the package name will
>>> change to o.a.c.codec2 and that the POM groupId will have to change
>>> from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
>>> live side by side.
>>
>> Yes, the name changes are necessary to avoid problems with incompatible jars.
>>
>>> I'd like to get this out of the way first hence topic 1.
>>>
>>>
>>> Topic 2: Beider-Morse (BM) Encoder API
>>> https://issues.apache.org/jira/browse/CODEC-125
>>>
>>> BM is a new codec for 2.0.
>>>
>>> The encode API returns a set of encodings.
>>>
>>> In trunk, this is currently a String in the format "s1|s2|s3".
>>>
>>> I think this is not the best design, a set should be a Set, in this
>>> case, an ordered set. Or, a List. Generally, it should be a Collection
>>> of Strings.
>>>
>>> There was concern with call sites that generically use a [codec]
>>> Encoder with the signature "Object encoder(Object)" and call
>>> toString() on the result.
>>>
>>> If we set the API to "CharSequence encode(Set<CharSequence>)" or
>>> "String encode(Set<String>)", doing a toString() on a HashSet will
>>> yield a usable String similar as to what trunk does now. For example,
>>> for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
>>> "[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
>>> documented and stable format.
>>
>> +1
>>
>>> Topic 3: Generics
>>>
>>> This will be in a separate thread but I'd like to get this in 2.0
>>> because this will likely break the API and I only want to break things
>>> once and not have to do a codec3 for generics.
>>
>> +1.
>
> I'll work on a generified codec2 over the next couple of days and
> present what that looks like, maybe in a branch, or a patch.
>
> Gary
>
>>
>>> Thank you all,
>>> Gary
>>>
>>> On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
>>> <turingatemyhamster@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> As those of you who've been following the CODEC-125 ticket will know, with
>>>> Greg's help I've got a port of the beider morse phonetic
>>>> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
>>>> ready for people to use and abuse. It ideally needs more test-case words,
>>>> but to the best of my knowledge it doesn't have any horrendous bugs or
>>>> performance issues.
>>>>
>>>> The discussion on the ticket started to stray off bmpm and on to policy for
>>>> releases and changing APIs, and Sebb said we should discuss it on the list.
>>>> So, here we are.
>>>>
>>>> Ideally, I'd like there to be a release of commons-codec some time soon so
>>>> that users can start to try out bmpm right away, and so that we can start
>>>> the process of adding it to the list of supported indexing methods in solr.
>>>> What do people think?
>>>>
>>>> Matthew
>>>>
>>>> --
>>>> Dr Matthew Pocock
>>>> Visitor, School of Computing Science, Newcastle University
>>>> mailto: turingatemyhamster@gmail.com
>>>> gchat: turingatemyhamster@gmail.com
>>>> msn: matthew_pocock@yahoo.co.uk
>>>> irc.freenode.net: drdozer
>>>> tel: (0191) 2566550
>>>> mob: +447535664143
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>
>
>
> --
> 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


Mime
View raw message