commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [CODEC] Base-n refactoring
Date Thu, 27 Jan 2011 21:16:40 GMT
On 27 January 2011 21:03, Gary Gregory <GGregory@seagullsoftware.com> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Thursday, January 27, 2011 15:13
>> To: Commons Developers List
>> Subject: [CODEC] Base-n refactoring
>>
>> I think I've now got the Base32 classes to a reasonable state. (More
>> tests are surely needed).
>>
>> I decided to drop all the static encode/decode methods, as this
>> simplifies the class considerably.
>> Perhaps one are two are needed, but it might be best to release
>> without them and add later if there is a big demand.
>>
>> The default buffer size is quite large (8192), so I added an
>> overridable method to define it.
>> Users would have to subclass Base32 to use it, but at least the option is
>> there.
>> I did not want to add yet more parameters to the ctors.
>> If we ever decide to add an Options class then it could be added there.
>>
>> If the API looks OK, I'd like to rework the Base64 classes to use it.
>>
>> Thoughts?
>
> - A couple of Checkstyle issue (see Maven reports)
>
> - Some CPD issues that refactoring Base64 to BaseNCodec will clearly address.
>
> - Base32 code coverage is MUCH better. Cool.

Probably partly because I eliminated all the static methods...

> - method avail(): is there a better name: getAvailableBytes()?availableCount()? available()?
remainingBytes()?

Probably - this is the original method name.

java.io.InputStream uses available(), which seems OK.

> - It would be nice to make it easier to configure the buffer size without subclassing.
If I wanted a configurable class, I'd subclass and add an ivar... I know I know, the final
issue ;) and I agree more ctors is nasty.

At least it's possible now...

> Looking good for refactoring.
>
> Gary
>
>>
>> ---------------------------------------------------------------------
>> 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