commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [math] RandomData/RandomDataImpl
Date Mon, 21 Mar 2011 14:47:32 GMT
On Mon, Mar 21, 2011 at 9:35 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 3/21/11 7:14 AM, Matt Benson wrote:
>> On Sun, Mar 20, 2011 at 2:19 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>>> Le 20/03/2011 19:28, Phil Steitz a écrit :
>>>> 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?
>>> I also think the RandomDataImpl layer adds too much complexity for users.
>>> +1 to merge it in RandomData.
>>>
>> I don't follow [math] that closely, but the above isn't what I read
>> from Phil's original mail.  :/
>>
> Thanks, Matt, but I think Luc did understand what I meant.  Maybe
> you can help us decide.  Originally, almost everywhere in [math], we
> separated interface from implementation.  RandomData /
> RandomDataImpl remains an example of this.   I think what Luc is
> saying, and I tend to agree with him, is that in this particular
> case, the interface has little value and just adds unnecessary
> complexity for the user.  The aim to support the strategy pattern in
> this case is really satisfied internally to the Impl class - by
> allowing the underlying source of randomness to be provided by the user.
>
> So what we are talking about here is as part of the
> compatibility-breaking 3.0 release, we just make what is now an
> interface, RandomData, a concrete class and move the implementation
> in RandomDataImpl into that class.
>

I understood that part, but somehow I read that there was a second
interface involved as well, and this is where my confusion was based.
Rereading, this doesn't seem to be the case and I apologize for the
noise.  That'll teach me to trust myself to think shortly after
awakening.  :o

Matt

> Phil
>> Matt
>>
>>> Luc
>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message