> -----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. - method avail(): is there a better name: getAvailableBytes()?availableCount()? available()? remainingBytes()? - 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. 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
