commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <stei...@yahoo.com>
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java)
Date Thu, 19 Jun 2003 15:24:55 GMT

--- Al Chou <hotfusionman@yahoo.com> wrote:
> --- Phil Steitz <steitzp@yahoo.com> wrote:
> > --- Tim O'Brien <tobrien@discursive.com> 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.  

That does not bother me at all.  What I was objecting to was achieving this
delegation by means of (IMHO) a poorly defined class hierarchy.

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.  

I agree; but actually sticking to "Java-ish" design patterns makes it easier to
use for Java developers.

> 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.

If I understand what you are saying, this is not possible in Java, at least not
using the same class.  It is certainly possible to have one class expose a
static method with the same name, signature and semantics that another class
uses for an instance method.  For example, we could have UnivariateImpl expose
an instance method that did the same thing that a static method in StatUtils
did. Why we would choose to do that is unclear to me, but it is certainly
possible in Java.
 
> 
> 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). 

+1  

>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".
> 
> 
> Al
> 
> =====
> Albert Davidson Chou
> 
>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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


Mime
View raw message