Does it make sense to define a class like RegressionGlobalFitStatistics? It
would look like:
public class RegressionGlobalFitStatistics{
... private constructors
public double getRsquared(){
return _rsq;
}
public double getAdjRsquared(){
return _adjrsq;
}
... and so forth
}
The RegressionResults class would use static factory methods in
RegressionGlobalFitStatistics to properly instantiate the different fit
measures. One could even keep flags if a variable is set or not, throwing an
exception is someone is attempting to access data that has not been set. For
example,
public double getAdjRsquared(){
if( _adjrsqIsSet ){
return _adjrsq;
}
throw new MathException("Illegal Request");
}
I think you need to disambiguate between not setting a variable and a NaN
returned because of bad data or some other issue.
The inclusion of GlobalFitStatistics class inside of RegressionResults would
minimize changes to RegressionResults, since GlobalFitStatistics is most
likely to be the class that grows and changes over time.
Thoughts?
-Greg
On Wed, Jul 13, 2011 at 11:53 PM, Greg Sterijevski
<gsterijev...@gmail.com>wrote:
> I was not aware of the versioning document. Thank you. A few more things
> make sense now. It is still a bit bittersweet. In my opinion the interface
> is a programmer's most terrific tool. It keeps him honest as well. I
> understand your point though.
>
> -Greg
>
>
> On Wed, Jul 13, 2011 at 11:42 PM, Phil Steitz <phil.ste...@gmail.com>wrote:
>
>> On 7/13/11 9:05 PM, Greg Sterijevski wrote:
>> > Phil,
>> >
>> > "Fortunately for users, maybe less fortunately for developers, we
>> > can't really "evolve" our API rapidly .... This is why we
>> > favor abstract classes over interfaces."
>> >
>> > Just so that I am sure I understand, let me restate the objection to an
>> > interface. An interface approach is more likely to be used broadly, so
>> any
>> > changes which might be made would have a disproportionately large
>> impact. Is
>> > this correct?
>>
>> No, our rule is we make incompatible changes only in major
>> releases. See [1]. Changes to interfaces are incompatible changes,
>> so whatever interfaces we define we have to be prepared to live with
>> until the next major release. We have no way of telling who is
>> using what or how, so our rules are expressed simply in terms of
>> source and binary compatibility. Abstract classes can add
>> (non-abstract) methods without breaking compatibility. That is why
>> we favor them where possible over interfaces.
>> >
>> > Isn't this a bit of a punt? On the surface the user gets a guarantee,
>> but
>> > the guarantee is a deadend. If we decide a different approach is
>> warranted,
>> > the object is deprecated and ditched at some point. More importantly, if
>> it
>> > is a successful interface isn't that a good thing?
>> > If it makes its way into
>> > a lot of other code, then I doubt we will need to make many changes.
>> Also, I
>> > foresee a two track evolution of features. The interface defines the
>> basic,
>> > most limited set of functionality. Everything else is throw into
>> abstract
>> > and concrete implementations. When a functionality seems to exist in
>> most
>> > derived classes, then the debate should commence about its inclusion in
>> the
>> > regression interface. The evolution would most likely be new features
>> in, as
>> > opposed to current features cut out. There would be a lag of probably a
>> year
>> > in moving a new feature up the inheritance structure to the interface.
>> Maybe
>> > your experience is different. I could be wrong about user demands...
>>
>> What it comes down to is being certain that the core material that
>> we put into the interface is not going to change. Our experience in
>> Commons has been that that is often very hard to do and in most
>> cases abstract classes will serve the same purpose without imposing
>> the same kind of constraints. The evolution you describe above is
>> natural and bound to happen. Trying to avoid interfaces gives us
>> more flexibility in timing, enabling innovative change between major
>> releases.
>>
>> Phil
>>
>> [1] http://commons.apache.org/releases/versioning.html
>> >
>> > Thanks,
>> >
>> > -Greg
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
