commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [lang][collections] Utils having a public constructor
Date Mon, 12 Aug 2002 23:37:57 GMT
> 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.

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.

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

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. :)

-Paul



--
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