If the code has been tested by the folks at hadoop I trust it very much. (They do extensive testing!) and would be all for replacing the current code base. But IMO that's no blocker. In the end the algorithm should be a black box for everyone using compress. So changing this in a later release should be no problem.
I would strongly argue against shipping two code bases for the same algorithm. It would cause more confusion than it would help IMO. On Thu, Mar 26, 2009 at 12:47, sebb <seb...@gmail.com> wrote: > On 26/03/2009, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote: >> On Thu, Mar 26, 2009 at 12:36 PM, sebb <seb...@gmail.com> wrote: >> >> > Would it be a silly idea to include both variants? >> >> >> I'd clearly tend to avoid that. It would likely cause confusion. > > Surely that depends on how well it is documented and on the API? > > I've not looked into it, but perhaps the implementation can be chosen > at construction-time via a parameter. > >> On a related matter: Stefan, wouldn't it be possible for the others to >> start using compress? >> >> Jochen >> >> >> >> -- >> I have always wished for my computer to be as easy to use as my >> telephone; my wish has come true because I can no longer figure out >> how to use my telephone. >> >> -- (Bjarne Stroustrup, >> http://www.research.att.com/~bs/bs_faq.html#really-say-that >> My guess: Nokia E50) >> >> >> --------------------------------------------------------------------- >> 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
