On 27 January 2011 21:03, Gary Gregory <ggreg...@seagullsoftware.com> wrote: >> -----Original Message----- >> From: sebb [mailto:seb...@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-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
