commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <>
Subject Re: [lang][collections] Utils having a public constructor
Date Mon, 12 Aug 2002 23:55:40 GMT
"Jack, Paul" <> writes:

> > Velocity treats anything you put into its context in a bean-like
> > fashion.  I agree that StringUtils is not a JavaBean.  Regardless,
> > Velocity is able to use it in a bean-like fashion as long as there is
> > an accessible ctor.  What value is there in preventing this behavior?
> > Allowing this behavior allows re-use of Commons code, which directly
> > matches the charter under which Commons components operate.
> I guess I don't see the value in promoting the behavior.  Giving 
> StringUtils a protected constructor just for Velocity seems like
> a band-aid for a larger issue, which is that Velocity can't use
> ANY library of static utility methods unless it has a public 
> constructor, which discounts many static libraries out there.
> In the long run I think a change to Velocity would make more sense.

Paul, this isn't a Velocity-only issue.  Any bean-esque system which
desired to use the utility classes would see the lack of protected or
public constructor as a limitation in the Commons library.

> There are valid reasons for keeping things as private as possible.
> There are many cases in [collections] where bugs were found, or 
> where algorithms could be more efficient, but we couldn't change
> the existing code because it exposed protected fields that we wanted
> to delete, or because it used a protected method whose signature
> we couldn't change because it would break backwards compatibility.

I agree that information/implementation hiding is a good thing.  I'm
missing how this applies to addition of a constructor to classes
consisting of static methods.

> Having said that, I won't -1 any protected constructors in commons
> utility classes, I'll just think they're really wierd.

Fair enough.

> And I really would consider allowing Velocity to invoke statics
> without instances, as that really would give users greater 
> flexibility.  I'll help if you'd like. :)

Thanks for the offer.  ;) The implementation of such a thing is
trivial, but would break backwards compatibility.  I mentioned that
there are hooks for plugging in implementations which can have this
sort of behavior.

As I also mentioned to Stephen C., the behavior you suggest provides
no way to indicate whether you want to invoke methods of the Class
instance you add to the context, or methods of the class which it

I think this issue died a few messages ago, but we could certainly
continue to beat it.  In any case, it's nice to hear people's views.

Daniel Rall <>

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

View raw message