Re: [guppi-list] Re: Problems with cvs goose and a new commit
- From: Jon Trowbridge <trow emccta com>
- To: The Guppi Mailing List <guppi-list gnome org>
- Subject: Re: [guppi-list] Re: Problems with cvs goose and a new commit
- Date: Mon, 19 Jul 1999 11:11:41 -0500
On Mon, Jul 19, 1999 at 03:34:38PM +0200, Asger K. Alstrup Nielsen wrote:
> If you think we should change it, of course we will, but I think we
> should keep the current ResultStruct which has place-holders for both
> the corrected and non-corrected results. Then, we could add a bool
> to decide whether to use the "intelligent automatic" approach that
> will only fill in the relevant values (and a flag to describe what it
> did), or the brute-force approach which will calculate everything
> regardless of whether we really need to or not.
I think that this is a very reasonable approach, since it avoids a
struct-proliferation --- having FooResultsWithTies and FooResultsNoTies
structs would be gross.
Of course, this solution is a bit C-ish. Another alternative would be
to make the results-object a class, with accessor functions rather
than raw data to check. The benefit of this would be that the
accessors could throw an exeception if the "wrong" data is read, as in:
class FooResults {
public:
FooResults() { ... }
bool without_ties() const { return without_ties_; }
double foo_stat() const {
if (!without_ties()) throw SomeException;
return foo_stat_;
}
double p_value() const {
if (!without_ties()) throw SomeException;
return p_val_;
}
... etc ...
private:
bool without_ties_, with_ties_;
double foo_stat_, foo_stat_with_ties_;
double p_val_, p_val_with_ties_;
};
As long as we used a standard set of accessor names (i.e. didn't call
it p_value() in one place and p_val() in another...), I think that
this would be a pretty nice, safe, "user-friendly" approach.
-JT
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]