commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil O'Toole <>
Subject Re: [collections] Refactoring decorators
Date Mon, 28 Apr 2003 23:50:05 GMT
I think it's a good idea, and generally exposing the private classes is
a good idea as well. This is after all a utility package, and the
people using the package are big boys and girls, and can handle seeing
all these extra classes. And I'd be all for the #decorate method name
over #create. It isn't necessarily the case that each call to
#decorate/create will create a new object (e.g. a call to, say,
unmodifiableArrayIterator or somesuch might return a singleton
EMPTY_ITERATOR if the array was empty).


--- Rich Dougherty <> wrote:
> Stephen Colebourne wrote:
> > Following a recent thread
> >
> > I have been thinking about how to best structure the decorators in
> > [collections].
> > 
> > [snip]
> > 
> > Looking at it and the continuing RFEs, some kind of change is
> needed, and
> > soon. Any objections?
> This sounds like a good idea to me.
> Exposing a bigger public API makes it easier for those of us outside 
> Apache who want to write collections. I sometimes need to patch 
> Collections to reuse all those handy (but private) classes. However,
> I 
> can certainly sympathise with the increased maintenance and 
> responsibility that a bigger API that. This is probably why Sun
> doesn't 
> let us get at the handy (but private) collection classes lying idle
> in 
> java.util.
> Just one suggestion... perhaps decorate() might be a better name for
> the 
> static method. My rationale is that the methods do not necessarily 
> create a new object. Not a biggie, of course.
> Rich

> ATTACHMENT part 2 application/pgp-signature 

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

View raw message