On Tue, 29 Jul 2003, Stephen Colebourne wrote:
> Date: Tue, 29 Jul 2003 23:50:35 +0100
> From: Stephen Colebourne <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: Re: [lang] DEVELOPERS-GUIDE.html
>
> ;-) I'll have another look at the differences once 2.0 is out. After
> ----- Original Message -----
> From: "Michael Heuer" <[EMAIL PROTECTED]>
> > Maybe we just try to convince the author(s) of UString to donate their
> > additional String-related static utility methods to the Jakarta Commons
> > project? ;)
>
> ;-) I'll have another look at the differences once 2.0 is out. After all
> I've already got a StringBuffer replacement I want to get in...
>
>
> > Overriding utility classes just seems icky to me.
> But icky is what backwards compatability is isn't it?
>
FWIW, our experience in commons-beanutils was that what we thought were
static methods that "everyone" would just use unmodified turned out not to
be the case, in two significant respects:
- Some people really do want to customize the behavior
of "standard" utilities, for various reasons.
- If you cache any data in static variables, you run into
complexities in environments like Tomcat, where you have
to throw away a class loader to implement webapp reloads.
(This issue is not relevant for static methods that
are stateless.)
We ended up implementing the Singleton pattern (with the specialization
that in a webapp environment it is really Singleton-per-webapp even if the
library is loaded from a parent class loader). For backwards
compatibility, the static method calls simply delegate to a standard
instance of the Singleton.
> Stephen
>
Craig
>
> > michael
> >
> >
> > On Tue, 29 Jul 2003, Henri Yandell wrote:
> >
> > >
> > > However, the following would work:
> > >
> > > UString ustring = new UString("foo");
> > > ustring.capitalise();
> > >
> > > if UString had:
> > >
> > > ...extends StringUtils...
> > >
> > > public void capitalise() {
> > > this.myStr = capitalise(this.myStr);
> > > }
> > >
> > > Not sure why someone would bother though :) Just as easy to do
> > > StringUtils.capitalise in there.
> > >
> > > Hen
> > >
> > > On Tue, 29 Jul 2003, Gary Gregory wrote:
> > >
> > > > Ah, but not really... ;-)
> > > >
> > > > A subclass cannot override methods that are declared static in the
> > > > superclass. In other words, a subclass cannot override a class method.
> A
> > > > subclass can /hide/ a static method in the superclass by declaring a
> static
> > > > method in the subclass with the same signature as the static method in
> the
> > > > superclass. Overriding only applies to instance methods, class methods
> > > > behave differently (ah, longing for Smalltalk). A class method can be
> > > > /shadowed/ by a subclass but not overridden (not to be confused with
> method
> > > > overloading of course ;-)
> > > >
> > > > Here is a fun experiment with statics that always comes and bites you
> in the
> > > > you-know-where:
> > > >
> > > > package test;
> > > >
> > > > class SubC extends SuperC {
> > > > static String hi() {
> > > > return "I am Sub";
> > > > }
> > > > }
> > > >
> > > > class SuperC extends Object {
> > > > static String hi() {
> > > > return "I am Super";
> > > > }
> > > > }
> > > >
> > > > public class TestSuperStatic {
> > > >
> > > > public static void main(String[] args) {
> > > > SuperC a = new SuperC();
> > > > SubC b = new SubC();
> > > > SuperC c = b;
> > > > System.out.println(a.hi() + ", " + a.getClass());
> > > > System.out.println(b.hi() + ", " + b.getClass());
> > > > System.out.println(c.hi() + ", " + c.getClass());
> > > > }
> > > >
> > > > }
> > > >
> > > > Can you guess what gets printed out? :-)
> > > >
> > > > (and no cheating by running the code!)
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, July 29, 2003 14:30
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] DEVELOPERS-GUIDE.html
> > > >
> > > > In this use case, everybody uses UString, so you can effectively
> override.
> > > >
> > > > If you code the same method in the 'subclass', and refer to it using
> the
> > > > subclass class then it will be called.
> > > >
> > > > Stephen
> > > >
> > > > ----- Original Message -----
> > > > From: "Gary Gregory" <[EMAIL PROTECTED]>
> > > > > When you do that, do remember that you cannot override static
> methods in
> > > > the
> > > > > same way that you can with instance methods.
> > > > >
> > > > > Gary
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, July 29, 2003 14:07
> > > > > To: Jakarta Commons Developers List
> > > > > Subject: Re: [lang] DEVELOPERS-GUIDE.html
> > > > >
> > > > > Because I want to create a subclass of StringUtils.
> > > > >
> > > > > Use case:
> > > > > I curently have a string utility class named UString.
> > > > > I plan to change that to extend StringUtils once 2.0 is released.
> > > > > (Because I'll get lots of extra methods for free)
> > > > > But I can only do that if StringUtils is not final.
> > > > >
> > > > > Stephen
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Henri Yandell" <[EMAIL PROTECTED]>
> > > > > To: "Jakarta Commons Developers List"
> <[EMAIL PROTECTED]>
> > > > > Sent: Tuesday, July 29, 2003 7:46 PM
> > > > > Subject: Re: [lang] DEVELOPERS-GUIDE.html
> > > > >
> > > > >
> > > > > >
> > > > > > Question just came up on [io].
> > > > > >
> > > > > > Why do we not make our XxxUtil classes final again? :) Anyone
> remember
> > > > or
> > > > > > should I trawl through the mail from last year?
> > > > > >
> > > > > > Hen
> > > > > >
> > > > > > On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote:
> > > > > >
> > > > > > > Plus1
> > > > > > > Stephen
> > > > > > >
> > > > > > > > from: Henri Yandell <[EMAIL PROTECTED]>
> > > > > > > > date: Tue, 29 Jul 2003 14:00:23
> > > > > > > > to: [EMAIL PROTECTED]
> > > > > > > > subject: Re: [lang] DEVELOPERS-GUIDE.html
> > > > > > > >
> > > > > > > >
> > > > > > > > Just noticed that DEVELOPERS-GUIDE.html doesn't mention
> whether our
> > > > > > > > XxxUtils class should be final or not. I'm pretty sure we
> ended up
> > > > > making
> > > > > > > > them not final. Anyone object to this before I add a line to
> the
> > > > > guide?
> > > > > > > >
> > > > > > > > Hen
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > > > 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]
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > 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]
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
