Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Mark R. Diggory wrote: Yes it is clearer, just for reference, my GC discussion at the beginning of this thread involved an article I read awhile back, this article suggested that objects that are created within a "static" method can get "stronger references" (or something along these lines) than their non-static counterparts and as such never actually get garbage collected over the life of the JVM. There are no stronger references than ordinary references. Except perhaps j.l.r.PhantomReference (somebody out there who knows what's this actually good for?) There are weaker references though. Perhaps it was meant said objects were referenced by static data, in which case they of course wont be GCd. Unless the object refers to further, perhaps continually growing data structures, this shouldn't cause problems even in a long running server. There are of course several other arguments against static methods and especially against using static data: enterprise java beans can't have static methods at all, and static data can easily become a headache in multithreaded environments. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
robert burrell donkin wrote: a slightly more sophisticated approach would be to make the utility delegate to a singleton instance of a object which can also be constructed. the user can then choose whether to construct an instance and then configure it or use the utility and use the standard settings. the library should *not* expose the singleton delegate or allow the user to set any state on that object. the user *must* create an instance in order to use any advanced features. this is the pattern that i would advocate for advanced booch utilities. Hopefully my new experimental architecture alleviates this issue for univariate stats. There are currently three ways to get at the individual stats in my experimental refactoring. Static StatUtils, Non-static Univariate implementations and Direct Instantiation of a particular "UnivariateStatistic". Various FrontEnd's <-- delegate to <-- Individual Stats. <--StatUtils <|Individual UnivariateStatistics <--Univariates <--|<-- (Mean, Var, Std, Sum, SumSq, <--Directly <-| SumLog, Skew, Kurt, Percentile...) The individual UnivariateStatistic's house the "guts" of the algorithms for both store based and storeless based calculations. You could instantiate these directly, call static instances of them via the StatUtils or Pickup a Univariate framework that will provide a "Standard Set" of them to work on a Storage Implementation. why? well, now consider the case when you allow the user to configure the booch utility directly (this is the beanutils case). now, so that you can isolate threads in different server side contexts, you need to use a pseudo-singleton - a singleton that is a singleton for each server side context rather than per classloader. this turns out to be non-trivial when you realize that every time a context is disposed of, everything needs to be garbage collected and that users are going to want to be able to subclass the bean pseudo-singleton. i hope this is a bit clearer now. - robert Yes it is clearer, just for reference, my GC discussion at the beginning of this thread involved an article I read awhile back, this article suggested that objects that are created within a "static" method can get "stronger references" (or something along these lines) than their non-static counterparts and as such never actually get garbage collected over the life of the JVM. I can't, for the life of me, find this article again to backup my statement... Which leads me to think it was a Red Herring. :-( -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
robert burrell donkin wrote: On Friday, June 20, 2003, at 05:34 PM, Phil Steitz wrote: 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. I am personally OK with this, as long as we limit the scope to relatively trivial computational methods. we came across this very problem in beanutils not too long ago. beanutils was originally written to use static utility methods. we ended up creating (pseudo-)singletons that do the actual work. this has turned out to have more than a few wrinkles (since jakarta components are designed to be used in server applications, there's a lot to think about when it comes to ensuring that objects can be garbage collection and that different web applications use independent versions of configurable library code). i personally think that there is probably room for a few headline classes of this type at the top of the hierarchy in order to make things easy for basic users. but i would probably advise developers of library code to prefer concrete objects for advanced classes. experience has shown that these may need to be sub-classed or have to make use of the strategy pattern later. i would say that retro-fitting these capabilities to an existing library can prove to be very non-trivial. anyway, i'll be interested to see what J.Pietschmann comes up with. - robert This is a really strong point Robert, I know there are real issues with objects that get created from a static point not getting garbage collected from some applications I worked on, I shouldn't have assumed it wasn't an issue in the server env. I'd have to say, this is the strongest point I've seen so far for singleton object usage over static util usage and its quite convincing to me. I think I actually have somewhat of an interesting solution to this. But I want to get it fully formalized to present to the group, I have an alternative implementation of some of the stat/StatUtil classes that I will present to the group within the next day or so. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Phil Steitz wrote: The limitation on overriding is a serious concern and that is why in an earlier post, I suggested that we never use static methods for complex algorithms. An argument could be made that it would have been better to implement the methods in StatUtils as instance methods and to provide a (singleton) instance factory for users. Have a look at UnivariateRealSolverFactory and check whether you like my approach to cater for both simplicity and flexibility. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Phil Steitz wrote: Mark R. Diggory wrote: David Graham wrote: I see no correlation between AOP and static methods, nor any correlation between static methods an increased code maintainability. There is nothing magic about static methods that make them more maintainable than non-statics. David http://www.eclipse.org/aspectj/ -Rob The discussion is growing somewhat repetative, OT and monotonic, unless anyone has a clearly differing view than whats been already voiced, I suggest we move on to more interesting development related topics, your probibly welcome to continue this discussion on the jakarta commons users/interest list. Cheers, I agree that this could go on and on and we should get back to work, but I think that David's main point -- that static methods limit flexibility and are not really necessary to support utility functionality -- is a good one and one which we should keep in mind. The limitation on overriding is a serious concern and that is why in an earlier post, I suggested that we never use static methods for complex algorithms. An argument could be made that it would have been better to implement the methods in StatUtils as instance methods and to provide a (singleton) instance factory for users. I think that this is a better general approach, but for the simple computational methods in StatUtils and MathUtils, convenience and efficiency outweigh the extensibility concern. Phil True, there is a balance that needs to be maintained between extensibility and efficiency/ease of use. David's comments about lack of extensibility in static methods is valuable. But, I certainly don't believe that static usage or instantiable objects are either right or wrong. They both have their place. I believe we based the design of the static utilities on the current Math design for consistency (not only in static aspects, but return value domain and behavior). 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. -- 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]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
David Graham wrote: Static methods are a necessary evil in OO languages and should be avoided when possible. I disagree. Static functions are similar to Aspect Oriented Programming, such as AspectJ which centrializes code across many classes that is similar in functionality. This eliminates duplicate code, and increases maintainability. I see no correlation between AOP and static methods, nor any correlation between static methods an increased code maintainability. There is nothing magic about static methods that make them more maintainable than non-statics. David Any time code is in --one-- place and not scattered across multiple classes this increases maintainability. The fact that the methods are static is beside the point. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
David Graham wrote: Static methods are a necessary evil in OO languages and should be avoided when possible. I disagree. Static functions are similar to Aspect Oriented Programming, such as AspectJ which centrializes code across many classes that is similar in functionality. This eliminates duplicate code, and increases maintainability. I see no correlation between AOP and static methods, nor any correlation between static methods an increased code maintainability. There is nothing magic about static methods that make them more maintainable than non-statics. David http://www.eclipse.org/aspectj/ -Rob The discussion is growing somewhat repetative, OT and monotonic, unless anyone has a clearly differing view than whats been already voiced, I suggest we move on to more interesting development related topics, your probibly welcome to continue this discussion on the jakarta commons users/interest list. Cheers, -- 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]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Static methods are a necessary evil in OO languages and should be avoided when possible. I disagree. Static functions are similar to Aspect Oriented Programming, such as AspectJ which centrializes code across many classes that is similar in functionality. This eliminates duplicate code, and increases maintainability. http://www.eclipse.org/aspectj/ -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
David Graham wrote: 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. Attaching methods to number objects makes them easily accessible too. 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). This isn't calculus, this is OOP. I'm of the opinion that in OOP you should always be passing messages to objects and static methods violate that principal. If I want to find the cosine of some number variable x it's more natural OOP to say x.cos(). cos(x) is a very procedural (read C) way of thinking and unnecesarily limits your implementation possibilities. True, but algorithms are easier to understand/debug when they are in a familiar syntax. I tend to think that "OOP you should always be passing messages to objects" is also something that can "limit" implementation possibilities as well. And philosophize a little, its always in the "cracks" where the interesting things grow. Is it in the conflict between procedural and OOD that elegant designs arise? There was a time I actually wrote my own primitive wrapper library. But, now I do feel a little differently about it now, in a procedurally implemented OO language like Java there as to be some point where the procedural and the OO aspects meet. I really hope for myself, to look deeper into Aspect Oriented Design to see if that is something that can fill that conceptual gap. Anyways, this discussion is purely academic because we're constrained by what Java actually allows. I'll let you math wizards get back to work ;-). David Always do feel free to "enthusiastically" join in when the subject interests you. :-) -- 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]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
David Graham wrote: --- 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. See my comment below. > 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". 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. 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]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Al, It sounds like the pattern you're proposing is the Strategy design pattern (see "Design Patterns" by the four authors). Basically, an object has multiple possible delegate objects, each of which implement a common interface. Then, as the state changes, the strategy can switch from one to another. This makes it transparent to the caller that multiple strategies are being used, and that they are even changing, but allows for good encapsulation, flexibility, and extensibility. As for invoking using either static methods or instance methods, the Commons Bean-Utils does this. There's a BeanUtils simpleton (all static methods) that delegates to a BeanUtilsBean, which can be instantiated, extended, etc. So, the most common/shared version is accessible from either way, but any specialized version must be instantiated yourself and called directly. Design Patterns are a great way to make Java do what we want it to. Eric Pabst |-+---> | | Al Chou | | | <[EMAIL PROTECTED]| | | hoo.com>| | | | | | 06/18/03 08:32 | | | PM | | | Please respond | | | to "Jakarta | | | Commons | | | Developers List"| | | | |-+---> >---| | | |To: Jakarta Commons Developers List <[EMAIL PROTECTED]> | |cc: | |Subject: [math] design patterns (was Re: cvs commit: | |jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java)| >---| --- Phil Steitz <[EMAIL PROTECTED]> wrote: > --- Tim O'Brien <[EMAIL PROTECTED]> 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". 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
