[lang] Summation [Was: [lang][collections] Utils having a public constructor]

[Henri Yandell <ba...@generationjava.com>]

A bit hard to get a true feel for just what all the views were in that
thread. I personally am +1 on having empty public constructors, but I
think I'm in a very small minority so I've been keeping quiet.

It seems that a workable compromise appears to be that XxxxUtils packages
would have a protected deprecated empty constructor which does _not_ throw
an exception.

Is this something that users of Velocity can use? We're not just
speculating wildly for a compromise which fails to fit users of such
tools?

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] Summation [Was: [lang][collections] Utils having a public constructor]

[Daniel Rall <dl...@finemaltcoding.com>]

Henri Yandell <ba...@generationjava.com> writes:

> A bit hard to get a true feel for just what all the views were in that
> thread. I personally am +1 on having empty public constructors, but I
> think I'm in a very small minority so I've been keeping quiet.
> 
> It seems that a workable compromise appears to be that XxxxUtils packages
> would have a protected deprecated empty constructor which does _not_ throw
> an exception.

Why deprecate the constructor?

> Is this something that users of Velocity can use? We're not just
> speculating wildly for a compromise which fails to fit users of such
> tools?

Velocity could use that given it provides an sub-class of StringUtils.
The same would be true for any other bean-esque system.  This is the
Right trade-off given it is not the use case the classes explicitly
are designed for.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>