I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish.Not for us, maybe, but it could be a real pain for the users who have written code using the static methods directly. We also need to keep reminding ourselves that what we are developing is a library for others to use. Refactoring public interfaces post release is a slow and painful process. Given that MathUtils and StatUtils are going to be public, we need to be committed to supporting the static methods that they will expose.
Now thats a very strong point,
A cautious side note: Its very difficult to design a product for a "hypothetical future user", I've been trying to do this for the last 3 years, its very very difficult, and I'm constantly "pulling in the reigns", to stop overdevelopment that is based on "bad assumptions" about what this hypothetical user-base is going to want. The user is, infact, part of the Open Source development process. This is where philosphies like, "Release early, Release often" become benificial. The user input is really needed to help drive the development direction properly.
I am personally OK with this, as long as we limit the scope to relatively trivial computational methods.
Phil
As well another excellent point, Where do we draw the line on the content of StatUtils? and what is a non-trivial computational method? If as an algorithm can be easily broken down into separate methods, it first seems a benefit to have those utility methods easily accessable for other alogrithms that may need them. We see this with mean, sum, sumq, etc in the statistics lib. However, optimized algorithms often combine the calculation of such utility methods to improve performance, sum and sumsq can be easily calcuated in one pass (or easily updated in a storageless case). In such cases is it a bad decision to promote the static usage of such methods, we see it happening in java.lang.Math? It is nice to have them as simple generic building blocks, but manyl optimal implementions could not directly benefit by using them. Math.pow is a standardized IEEE implementation, it is a generic and very stable solution but it is not the optimal performance solution in every case. Our StatUtils will probibly endup have the same such characteristics. Again, this doesn't suggest Static methods are bad, the same situation would arise if it were a regular abstract/base class. Its just the case that the methods that go into Utils have an appropriate definition of applicability that needs to be clearly defined.
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
