[lang][io] final classes

[Stephen Colebourne <sc...@btopenworld.com>]

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" <Ar...@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" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@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 <ba...@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