You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2011/03/20 19:28:00 UTC
[math] RandomData/RandomDataImpl
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] RandomData/RandomDataImpl
Posted by Matt Benson <gu...@gmail.com>.
On Mon, Mar 21, 2011 at 9:35 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/21/11 7:14 AM, Matt Benson wrote:
>> On Sun, Mar 20, 2011 at 2:19 PM, Luc Maisonobe <Lu...@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
Re: [math] RandomData/RandomDataImpl
Posted by Phil Steitz <ph...@gmail.com>.
On 3/21/11 7:14 AM, Matt Benson wrote:
> On Sun, Mar 20, 2011 at 2:19 PM, Luc Maisonobe <Lu...@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.
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
Re: [math] RandomData/RandomDataImpl
Posted by Matt Benson <gu...@gmail.com>.
On Sun, Mar 20, 2011 at 2:19 PM, Luc Maisonobe <Lu...@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. :/
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
Re: [math] RandomData/RandomDataImpl
Posted by Luc Maisonobe <Lu...@free.fr>.
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.
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
Re: [math] RandomData/RandomDataImpl
Posted by Phil Steitz <ph...@gmail.com>.
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 <ol...@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-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
Re: [math] RandomData/RandomDataImpl
Posted by Mikkel Meyer Andersen <mi...@mikl.dk>.
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 <ol...@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-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
Re: [math] RandomData/RandomDataImpl
Posted by Ole Ersoy <ol...@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-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