commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: Comment on (re-vote) XxxUtils constructors
Date Sun, 18 Aug 2002 14:14:18 GMT
From: "Geir Magnusson Jr." <geirm@adeptra.com>
> On 8/18/02 9:47 AM, "Stephen Colebourne" <scolebourne@btopenworld.com>
> > Jason was using the sandbox version of [lang]. During the tidying up for
> > promotion we fixed this as a bug fix, because private is the current
> > standard.
>
> I see.  I appreciate standards when there is a point.  What's the point of
> this one?
>
> This isn't what velocity might use.  It's what *users* of Velocity might
> use.  The Velocity core doesn't need such things - but users tend to use
> Velocity in frameworks where they setup lists of classes of which
instances
> are made available for use in the template.
>
> We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
> people to share and use.  If they now are going to evolve so people using
> Velocity and Turbine and Maverick and WebWork and... Can't share and use
> them, we'll just have to either make wrappers (stupid) or fork (even
> stupider) and keep available in Velocity or Turbine projects.

OK, I'll summarise the points.

The privateers argue:
These classes are just convenient places to place isolated methods. They
should not be instantiated, that wastes memory and is misleading to users.
ie. you don't need to instantiate to get the functionality. The Velocity
engine currently prevents these classes from being used, and there are
examples in Sun Java, java.util.Collections being notable. The core Velocity
engine could be changed to enable these classes to work, which would enable
access to all similar classes, whereas changing commons only allows access
to commons utility classes.

The protectedeers argue:
Sometimes it is useful to subclass utility classes, not because of an 'is a'
relationship, but simply to add more static utility methods. If Sun's
classes had protected constructors then commons CollectionsUtils would
probably have extended Sun's Collections. A protected constructor was
suggested as being acceptable to Velocity, however, it would appear to
suffer from the same issue of non-instantiability as private as its in a
different package.

The deprecated publiceers argue:
These classes are just convenient places to place isolated methods. They
should not be instantiated. However, tools such as Velocity have demostrated
that instantiation may be needed in certain circumstances. To enable
Velocity et al the constructor must be public. To disuade other coders from
instantiating the class it should be marked as deprecated, hance generating
a warning.

Stephen







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