--- Arun Thomas <[EMAIL PROTECTED]> wrote: > David, > > Keep in mind that the discussion is in the context of static methods, > not instance methods. Gary pointed out that there is a significant > difference between instance and static methods with respect to > subclassing: the former can be overridden - the latter only shadowed.
I'm fully aware of the inheritance rules regarding static and final methods. > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg23155.html > > People might definitely want to extend the class - I can see a need for > that. But that would require a different approach to the utility > classes; similar to the approach taken in struts and beanutils (e.g. > Singletons with instance methods rather than Class with static methods). > However, while we're discussing only classes which package together > static methods - does allowing extensibility make sense? There's at least one person in this discussion who needs to extend the utils classes so it doesn't make sense to declare the classes final. How does it benefit anyone by declaring a reusable library class/method final? David > > -AMT > > -----Original Message----- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 6:48 PM > To: Jakarta Commons Developers List > Subject: RE: [io][vote] FileUtils: decision on style > > > --- Neil O'Toole <[EMAIL PROTECTED]> wrote: > > > At first glance I don't really see the `need to override behavior' > > > argument -- if a user doesn't like the way a static method is > > > implemented, can't they just implement their own in a separate > class? > > > > > > > Absolutely. I don't see any reason why utility methods should be > > overridden. > > But other people *will* see a need, guaranteed. It's a rather limited > view to think that no one could ever possibly want to extend your > classes. This lesson has been learned the hard way in BeanUtils and in > Struts so I encourage you to rethink this strategy. > > David > > > If a method doesn't do what it says it does, it's broken > > and should be fixed in the next release. If you need the utility > > method to do something else, then it should have a different name to > > distinguish the funtional difference. > > > > Also, why would you ever need to extend non-instantiable classes? > > > > - Neil > > > > > > --- Michael Heuer <[EMAIL PROTECTED]> wrote: > > > On Tue, 29 Jul 2003, David Graham wrote: > > > > > > > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > > > > Hmmm.... From the last three notes - I think I understand > > > clearly the > > > > > motivation for requiring the public no-arg constructor, but I > > > still > > > > > don't understand the reasoning behind the need for avoiding > > > final. The > > > > > only reason I can see (with possibly poor vision) is to allow > > > access to > > > > > the methods of the utility class plus additional specific > > > > > methods > > > with > > > > > a handle on only one class object or utility instance (of the > > > subclass > > > > > utility). This seems to me to be very poor design if such a > > > constraint > > > > > exists. Can anyone see any other value to extending utility > > > classes > > > > > with entirely static methods? > > > > > > > > Because static methods can't be overridden you may as well declare > > > them > > > > final. However, static methods are truly evil. As soon as you > > > think no > > > > one will ever need to override the behavior, some user will come > > > along > > > > with a need to do so. This happened in Struts and now we're > > > replacing all > > > > the static methods with Singleton classes with instance methods. > > > > > > Is the struts mailing list the best place to go archive-digging on > > > this topic? At first glance I don't really see the `need to > > > override behavior' > > > argument -- if a user doesn't like the way a static method is > > > implemented, can't they just implement their own in a separate > class? > > > > > > michael > > > > > > > > > > > > > > David > > > > > > > > > > > > > > Cheers, > > > > > -AMT > > > > > > > > > > -----Original Message----- > > > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > > > Sent: Tuesday, July 29, 2003 11:44 AM > > > > > To: Jakarta Commons Developers List > > > > > Subject: RE: [io][vote] FileUtils: decision on style > > > > > > > > > > > > > > > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > > > > > Can someone expound on this "lesson"? The Developers Guide > > > mentions > > > > > > neither the rule that "final" should be avoided, nor the rule > > > that a > > > > > > public constructor is required. I'd love to know the > > > > > > reasoning > > > - is > > > > > > there some reason that actually derives from the constraints > > > > > > of > > > lang, > > > > > > or is it due to constraints on how other systems use lang? > > > > > > I'm particularly confounded by why the use of final would be a > > > problem. > > > > > > > > > > Marking a class as final prevents subclassing which is an > > > > > extraordinarily bad idea in generally available framework > > > classes. This > > > > > also goes for methods. Classes without default constructors are > > > not > > > > > JavaBeans and thus cannot be dynamically created and used in > > > certain > > > > > environments. > > > > > > > > > > David > > > > > > > > > > > > > > > > > Cheers, > > > > > > -AMT > > > > > > > > > > > > -----Original Message----- > > > > > > From: Henri Yandell [mailto:[EMAIL PROTECTED] > > > > > > Sent: Tuesday, July 29, 2003 5:55 AM > > > > > > To: Jakarta Commons Developers List > > > > > > Subject: Re: [io][vote] FileUtils: decision on style > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: > > > > > > > > > > > > > Hey thanks for the heads up! > > > > > > > > > > > > > > being one of the original authors/contributor of this class, > > > I do > > > > > > > have > > > > > > > > > > > > > some comments (mostly in favour of your proposal)... > > > > > > > > > > > > > > 1rst: you seem to have added a private constructor to > > > > > > > prevent instantiation, which hurts usage as in velocity, > > > > > > > where you > > > need an > > > > > > > instance of a class to allow the introspection to work. I'm > > > -1 for > > > > > > > that change in CVS. > > > > > > > > > > > > Yep. This is a Lang-lesson. Have an empty constructor in every > > > 'Utils' > > > > > > > > > > > class which mentions in a javadoc that this is not intended to > > > be > > > > > > used: > > > > > > > > > > > > /** > > > > > > * <p><code>ObjectUtils</code> instances should NOT be > > > constructed > > > > > > > > > > > in > > > > > > * standard programming. Instead, the class should be used > > > as > > > > > > * <code>ObjectUtils.defaultIfNull("a","b");</code>.</p> > > > > > > * > > > > > > * <p>This constructor is public to permit tools that > > > require a > > > > > > JavaBean instance > > > > > > * to operate.</p> > > > > > > */ > > > > > > > > > > > > Also worth looking at and maybe adopting the relatively > > > > > > simple: DEVELOPERS-GUIDE.html in Lang. Mainly it just outlines > > > > > > > the > > > XxxUtils > > > > > > philosophy. > > > > > > > > > > > > Also don't make XxxUtils a final class. > > > > > > > > > > > > Hen > > > > > > > > > > > > > > > > > > > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
