commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject Re: [lang][collections] Utils having a public constructor
Date Tue, 13 Aug 2002 04:24:38 GMT
Jack, Paul wrote:
> Actually, I've been thinking for a while now that I'd like to see
> the utility constructors in [collections] be, at least, protected.
> That way people could extend our libraries to add their own static
> utility methods and inherit all of ours.  For instance, we can't
> use the JDK's naming convention (making an interface name plural)
> because they made java.util.Collections's constructor private.  If
> they had made it protected, we'd have been able to extend it to add
> our own utility methods; people could get all of our new utilit
> methods just by changing the import...

I'd be ok with that...

> So, I'm not against visible constructors.  However, in my ideal 
> universe, the constructors are (1) protected to make it clear what
> they're for and (2) exceptional; any attempt to actually instantiate
> a CollectionUtils would raise a runtime (um, UnsupportedOperation?)

so the implementation of the protected constructor would just throw an 
exception?  sounds ok to me, although it doesn't help velocity people 
that need an instance of an object.

> Would the Velocity folks mind including something like this in 
> Velocity:
>     public class Util extends Object {
>         final public StringUtils string = null;
>         final public ObjectUtils object = null;
>         final public CollectionUtils collection = null;
>         public Util() {
>         }
>     }
> Then they'd use the Util class instead of the individual libraries;
> and could invoke the methods by saying Util.string.method() instead
> of StringUtils.method().

hmmm..  on first read of that, I thought, "Does that actually work?" 
But then I thought about it some more, and realized that it probably 
would...  too bad I'm too exhausted right now to actually try it out. 
Theoretically, this would solve the velocity "problem" without requiring 
exposure of a constructor for an object that never should be constructed.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message