velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: StringUtils constructor is private
Date Mon, 12 Aug 2002 21:21:39 GMT
"Stephen Colebourne" <scolebourne@btopenworld.com> writes:

> From what little I know about velocity I think I see the problem. Velocity
> needs an object to make method calls against. StringUtils can't be an
> object. Hence the problem.

Correct.

> However, really this is a Velocity issue, not a commons one. Its a general
> principle that all static utility classes (ie. those with only static
> methods) should have a private constructor. We don't want people creating
> instances, because they are not objects merely a convenient groupings of
> methods. If Velocity can't handle that it excludes virtually every static
> utility class.

Any static method in Java is callable via an instance of the declaring
class.  Just as Java supports this, Velocity does too.  Example:

public class Foo {
  public static String bar() { return new Object(); }
}

Foo.bar() -> Object
new Foo().bar() -> Object

context.put("foo", new Foo());
#set ($bar = $foo.bar())

> But given Velocity is broken, I suppose we have to do something. Either a
> public constructor or a public static final instance variable 'INSTANCE'
> would do. But I hate the very thought of it. And it affects all of
> [collections], [pattern and [lang].

Velocity is not broken -- it simply requires a class instance to
reference methods of that class.  Valid in Java, valid in Velocity.

Other work-arounds include an instantiable extension class (meaning
we'd make the StringUtils constructor protected, perhaps a good idea
regardless), or a wrapper class which delegates to the utility methods
(which is fairly gross).

What would be really convenient is a class with hooks into the
Velocity internals which takes a Class object in its constructor and
invokes methods via reflection (much as Velocity does anyhow), using
Velocity's internal introspection and/or uberspection caches.

-- 

Daniel Rall <dlr@finemaltcoding.com>

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


Mime
View raw message