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

Reply via email to