commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [VOTE] (re-vote) XxxUtils constructors
Date Thu, 22 Aug 2002 19:25:47 GMT
Classes like StringUtils used in Velocity this way :

  context.put( "tools", Class.forName(className).newInstance() );

I will be happy if it will look like this:

  context.putStatic( "tools", Class.forName(className) );

But it is more for Velocity list, not for commons or about StringUtils as
special case.

>
> What would be the Velocity change needed for this? Could someone who knows
> velocity show me how velocity usage of StringUtils looks now and how it
> would look with this change?
>
> Vel is always on my todo list it seems.
>
> Hen
>
> On Thu, 22 Aug 2002, Stephen Colebourne wrote:
>
> > Michael,
> > Please do not write a special tool for generating source code to solve
this.
> > The following code will do the trick:
> >
> > public class StringUtils {
> >     private StringUtils() {
> >         super();
> >     }
> >
> >     public static class Bean extends StringUtils {
> >         public Bean() {
> >             super();
> >         }
> >     }
> > }
> >
> > You can't do new StringUtils();
> > You can do new StringUtils.Bean();
> >
> > Standard inner class behaviour allows the utils class to be private, yet
> > provide an adaptor bean that is public. This is very low maintainance
;-)
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Michael A. Smith" <mas@apache.org>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > Sent: Thursday, August 22, 2002 5:26 PM
> > Subject: Re: [VOTE] (re-vote) XxxUtils constructors
> >
> >
> > > On Thu, 22 Aug 2002, Henri Yandell wrote:
> > > > You have seen nothing but an attempt to compromise. Suggestions of
> > static
> > > > instances, of extensions, of deprecation, of final are all attempts
at
> > > > compromise. It's been a heated debate yes, and one which has failed
to
> > > > reach a compromise, but large parts were learning about Velocity
> > abilities
> > > > and ideas which died due to being too high maintainance.
> > >
> > > Speaking of compromises, was there any objection to the bean wrapper
> > > class idea other than maintenance?  If I can eliminate the maintenance
> > > from this idea (by volunteering for now, and later to build a tool to
> > > automate the process), are there any other objections to the idea?
> > >
> > > regards,
> > > michael
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


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


Mime
View raw message