Hi, In my opinion, we have to be careful. It's not that I don't like the idea, but it might be a slippery approach merging interfaces with the uniquely implementing class - where do we stop merging?
Also, RandomDataImpl actually does have substantial non-trivial functionality like hexStrings, Poissons etc. which users easily could want to implement otherwise. So we really have to be careful. I think that we at least should send an e-mail out on the user-list and hear if anybody has any thoughts in this regard. Cheers, Mikkel. 2011/3/21 Ole Ersoy <ole.er...@gmail.com>: > Phil, > > I like the concrete class idea as well. > > Cheers, > - Ole > > On 03/20/2011 01:28 PM, Phil Steitz wrote: >> >> Quite a few methods have been added to RandomDataImpl that are not >> in RandomData. The methods were added to the impl class only to >> preserve backward compatibility in versions 1 and 2. In 3.0, we now >> have the choice to add the methods to the interface or even dispense >> with the interface altogether. Personally, I am leaning in the >> direction to just make RandomData a concrete class and move the >> implementations in RandomDataImpl into that class. Early on, we >> thought that RandomData might be a relatively small but useful >> interface. What I think now is that the more valuable >> interface/implementation separation is at the lower level of random >> generators, which is enabled in RandomDataImpl. >> >> What do others think about this? >> >> Phil >> >> >> >> --------------------------------------------------------------------- >> 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
