On 3/21/11 12:14 PM, Mikkel Meyer Andersen wrote: > 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. Thanks, Mikkel!
That's why I asked. I guess it comes down to whether users can accomplish what they may need via subclassing vs. alternative implementation of the interface and does the interface have value itself. You are right this is a slippery slope as it could be applied to quite a few other classes / interfaces (e.g. the distributions). I wanted to start the discussion using this specific example with hopes that it would bring out some principles that we could agree on as we plan 3.0. Would appreciate your thoughts on this. Phil > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
