commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <>
Subject [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat
Date Thu, 19 Jun 2003 02:32:34 GMT
--- Phil Steitz <> wrote:
> --- Tim O'Brien <> wrote:
> > On Tue, 17 Jun 2003, Mark R. Diggory wrote:
> We all agree that the optimized double[]|-> double computations should be
> reused.  The problem with the above is that you can't "dynamically"
> reorganize
> class hierarchies.  UnivariateImpl either "is" an AbstractStoreUnivariate or
> it
> "is not".  IMHO, it is not.  If we want to define an abstract base class for
> everything, it needs to contain only the things that *all* Univariates
> *always*
> implement.  Throwing runtime exceptions when an instance is not a "full
> instance" is not acceptable.

Off topic here, but not having been a practicing OO programmer for very long
(though having read books on C++, Java, and Objective-C over the past several
years), and that mostly in Ruby, which is dynamically typed, I'm of two minds
here.  While I support a clear inheritance hierarchy and understand and value
the desire to have an object be of either one class or another, it doesn't
bother me quite as much as it does Phil and Tim for an object to delegate to
different classes under different circumstances.  I would prefer that
commons-math be easy for users to use than for it to stick closely to typical
Java designs just for the sake of staying Java-ish.  Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in my way rather
than letting me solve the problem at hand in a natural way.  For example, one
thing I would have liked to see is the ability to invoke methods by the same
name either via static class methods or via instance methods of objects (where
appropriate and useful, of course).  I don't have enough experience with Java
to know if that's possible, though I suspect it would be difficult at least.

In any case, to keep our hierarchy design simple and clear, I do support
factoring out the StatUtils class.  As Einstein said, make it as simple as
possible (but no simpler).  I just want to see us keep an open mind about other
designs in the future if they turn out to be worthwhile, even if not exactly
the way "everybody else does it".


Albert Davidson Chou

    Get answers to Mac questions at .

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message