Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <006f01c35623$d340f6c0$db0c29d9@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <Pine.GSO.4.44.0307291809150.23172-100000@shell3.shore.net>
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Date: Tue, 29 Jul 2003 23:50:35 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

;-) I'll have another look at the differences once 2.0 is out. After
----- Original Message -----
From: "Michael Heuer" <heuermh@acm.org>
> 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?

Stephen


>    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:scolebourne@btopenworld.com]
> > > 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" <ggregory@seagullsw.com>
> > > > 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:scolebourne@btopenworld.com]
> > > > 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" <bayard@generationjava.com>
> > > > To: "Jakarta Commons Developers List"
<commons-dev@jakarta.apache.org>
> > > > 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 scolebourne@btopenworld.com wrote:
> > > > >
> > > > > > Plus1
> > > > > > Stephen
> > > > > >
> > > > > > >  from:    Henri Yandell <bayard@generationjava.com>
> > > > > > >  date:    Tue, 29 Jul 2003 14:00:23
> > > > > > >  to:      commons-dev@jakarta.apache.org
> > > > > > >  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:
commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org