See my comment below.
--- David Graham <[EMAIL PROTECTED]> wrote:
> > > 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.
>
> You're not alone in that belief. I've heard several people comment about
> how easy it is to code Smalltalk when exploring new solutions.
>
> > >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.
>
> Static methods are a necessary evil in OO languages and should be avoided
> when possible. The entire Java Math class is a perfect example of poor
> design because it's just a bunch of static methods.
I agreed with you upto that last sentence, My viewpoint: The whole point of the java.util.Math class is that the functions are so "standardized" and so "final" (on top of that mostly "native") that they shouldn't really ever be "overridable", they are "utility" functions that one can "rely" to be of a specific mathematical/numeric behavior. They are static as well to be easily accessible. IMHO, Static functions are the closest Java ever comes to allowing developers to define their own "operators". They are as analogous to the concept of mathematical functions as you can get. Did you ever write -1.cos() in Calculus? no, you wrote cos(-1) , and in java Math.cos(-1). And, unless some genius comes along and shows us a better way to compute cos(-1), your going to want to rely on a standard implementation that everyone uses to do cos(), otherwise you go an write your own class.
> It would have been
> *much* simpler to make numbers objects and allow -1.abs() type semantics.
> Anyways, my main point is that statics exist in Java to make certain things
> easier, not to allow the type of thing you describe.
I disagree. IMHO, in good OO design there is a place for utility classes that
encapsulate operations on objects, apart from the objects themselves.
Call me a brute, but Math.max(x,y) is more natural syntax to me than x.max(y).
The reason to avoid static methods in Java, IMHO, is that they cannot be
overriden, not that using utility classes in general is "bad design".
Another example of this the finality of java.lang.Number's like Double, Integer, etc. At first when I started to work with them, I wanted to be able to do things like
Double x = new MyDouble(1.0); Double y = new MyDouble(2.0); Double z = x.add(y);
But, this again introduces room for a sort of operator overloading which Java works hard to avoid (KISS). I now see why this is unfavorable.
MathUtils and StatUtils fall under this branch of design, they are die hard final implementations of a specific function that will be capable of being relied on in a similar fashion as the Math class.
Exactly. Any time you need a utility class with static members you can replace it with a Singleton object with non-static methods.
If there are other reasons for making methods static, then this just introduces unnecessary complexity. Math.pow(x,y) is always much easier to do than
Math math = Math.newInstance(); math.pow(x,y);
(not that, this is very hard at all either).
Now, the benefit of having both StatUtils and AbstractStoreUnivariate, is that you now have easy static reliable, final access via StatUtils when you want it, and you can override/extend the capabilities of AbstractStoreUnivariate when you want to create a custom implementation of an approach. Tim, Phil and Al were quite right to have me rollback what I had initially committed, this is far more flexible. Flexibility is very important in the initial stages of project development.
Finally, I really feel Aspect Oriented Programming (http://aosd.net) really takes OOP to the next level where some class/objects are now acting as functional relationships between other classes/objects. I would be more interested in how AOP could be applied to our libraries vs good ol' OOP.
Cheers, -Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
