commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [VOTE] (re-vote) XxxUtils constructors
Date Thu, 22 Aug 2002 13:49:20 GMT
Hi,
I am Velocity user and just want to see *additional* support for static
methods,
It is "max" I can to propose, but possible to implement "min" like
context.put("math", Math.class );
Instances with static methods can be supported without any changes.

I do not think "public" constructor is "bad" for static classes, but it is
useless for "tools".
We can have StringUtils with public or protected constructor, but It will
not help for "math" case. I do not believe my proposal for "namespace" is
the best, very possible
to find some better ways after disscussions (like to save memory), but I
will be happy if it will be possible to use "final/private" and it will make
templates more "clear".

As I understand this problem exists not because "public is good/bad",
 but because it breaks donor project, and can't become "private" in the
first release.

And I think I can do nothing more in this war :)

----- Original Message -----
From: "Geir Magnusson Jr." <geirm@adeptra.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Thursday, August 22, 2002 2:58 PM
Subject: Re: [VOTE] (re-vote) XxxUtils constructors


> On 8/22/02 4:07 AM, "Juozas Baliuka" <baliuka@mwm.lt> wrote:
>
> >
> > Current version (1.0-b1) of Lang StringUtils has private constructor.
> > I propose to change it to "public depricated" in commons-lang-1.0 and
> > "private final" in commons-lang-2.0 and up.
> >
> > It will help for "tools like Velocity" to support "static utilty
classes" ,
> > tools will have time
> > to implement support for something like this or "better" :
> >
> > context.putClass( "Math", Math.class );
> >
> > context.putClass( "Strings1", loadClass( className1 ) );
> >
> > context.putClass( "Strings2", loadClass( className2 ) );
> >
> > /* add static methods to default namespace */
> >
> >
ontext.getGlobalNamespace().add(   "Math"  ).add("String1").add("String2");
> >
> > /* add static methods to StringUtils namespace */
> >
> > context.addNamespace(   "StringUtils"  ).add("String1").add("String2");
>
> So you are suggesting we change our core APIs so you don't have to add an
> empty, public CTOR to the utility class?   And then everyone who has
> implement a custom context implementation will also have to change?
>
> Do you think that the additional data structures required to support the
> above will be far less than the 12 bytes you are 'saving' for us by not
> letting us put an instance of the class into the context?
>
> In the process, we'll have to add to every web framework that has support
> for Velocity as a templating engine (Turbine, Struts, Maveric, WebWork,
> Melati, ...) a way of specifying in the toolbox definition the way that
the
> user-specified tool class should be loaded, but I am sure that won't
amount
> to more than 12 bytes either...
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> 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