Now that the main Base-N refactoring is done, the door is open for Base16 ;) Juluis, you had mentioned Base16 before, any interest?
Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Thursday, January 27, 2011 16:17 > To: Commons Developers List > Subject: Re: [CODEC] Base-n refactoring > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
