commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang][io] final classes
Date Wed, 30 Jul 2003 08:15:00 GMT
From: "Arun Thomas" <Arun.Thomas@solidusnetworks.com>
> I agree completely that backwards compatibility is important!  Your
earlier comment: "I plan to change that to extend StringUtils once 2.0 is
released" led me to assume that Ustring does not currently extend
StringUtils.  If that is the case, I'm terribly confused as to how backward
compatibility is an issue at all?  These users do not currently dependent on
StringUtils functions - in future, as long as they are informed of the
existence of StringUtils, could they not begin to use those functions in
addition to those in UString?

Because I will remove methods from UString that are now replaced by an
equivalent method in StringUtils.

> That said, I jumped in to a thread on [io] regarding following the lang
pattern for XxxUtils only to understand the rationalle behind the design
decision to not make such classes final.  Until starting to use the commons
tools, I'd taken it for granted that making Util classes final was a
sensible design choice - I was startled to see that a consensus to the
contrary had been reached by the commons-lang/io community and wished to
understand the reasoning behind it.

When the private /public constructors debate came up I was equally startled
;-) Strange what OSS teaches you.

Stephen

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Tuesday, July 29, 2003 4:56 PM
To: Jakarta Commons Developers List
Subject: [lang][io] final classes


Please don't miss the point here!

I have 30 developers, and many projects, all happily using the class
UString. I don't want them to all have to change their code. (Its called
backwards compatability....)

By subclassing, I add lots of new methods (that are in StringUtils, and not
in UString) without breaking any old code. Maybe over time a migration to
just StringUtils will occur, I don't want to decide yet.

Now, we can sit here and say that its bad design, or that methods should be
added that forward the method call, etc.etc. But thats just uneccessary
hassle.


If you look back in the archives, you'll find a similar discussion about
public versus private constructors in [lang]. On that occasion I argued for
[lang] to be really tight and have private constructors because that was
'Good Design Practice'. I WAS WRONG.

Of all the lessons that OSS has taught me, its not to second guess the user
like this. Yes this means that the user can make mistakes and do 'stupid
things'/'bad design'.  But thats their perogative. We need to give our users
as much power as possible. If they abuse that power then fine.

(And please note, that anything applying to [lang] applies equally to [io]
as far as XxxxUtils goes)

Stephen

----- Original Message -----
From: "Arun Thomas" <Arun.Thomas@solidusnetworks.com>
So this saves one import for every user of Ustring that needs to use a
function currently available in StringUtils?  Not meaning to be sarcastic at
all - it just seems that this is the only savings you get.  Even the
documentation lookup will probably have to go to the JavaDoc for
StringUtils?

-AMT

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Tuesday, July 29, 2003 2:07 PM
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


Mime
View raw message