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?
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. I also accept that sometimes the only rationalle is current use patterns. Cheers, -AMT -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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" <[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]
