commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arron Bates" <ar...@keyboardmonkey.com>
Subject Re: [collections] - Few more collections for the masses... (impor tant for Struts view objects, maybe other projects)
Date Sun, 19 May 2002 15:10:55 GMT
> From: Arron Bates <arron@keyboardmonkey.com>
> > > Viewed as a lazy instantiation group of collection proxies, I think that
> it
> > > could be useful for commons. Of the 8 possible types that have been
> > > mentioned, lazy instantiation is applicable to all. For LazyCollection,
> the
> > > only access is via an iterator. The iterator should loop through the
> > > collection and on the next() method should return a newly created object
> if
> > > it was about to return null. For LazyList the code remains roughly as
> you
> > > have it, except that DeadObject is relaced by null. And so on.
> >
> > Nulls don't really work though. Do all list implementations allow null
> > values?... Can we assume this?... I wasn't going to.
> 
> The java supplied collections allow nulls. A null rejecting collection would
> be a special case. As such I would have no problems with the javadoc of
> LazyList stating that nulls are used as placeholders.


Well, using the empty object rather than null would mean that people could
rely on nulls being present, and not being destroyed when this helper class
does it's clean-up. Or, how about a compromise, where by it's set with a
member variable?... "boolean allowNull()" ?... works for me.


Just had a look through the Predicate classes. I *really* don't want the lazy
collections all in one class like this. It's so much easier to code against
separate classes. In this case, it's all semantics, and it's esier to read and
use the code as separate classes. It's also easier for us to maintain
ourselves separately, rather than one monumental class.

I see no real benefit from working with these factory methods. The coder
already knows the collection they want, and have to tell Predicate this
explicitly. It'd be different if it was one class, one static method, but it's
not. Internally, it's being done just as if they'd constructed the class
themselves. I don't have any bones with what the Predicate wrappers do, but
the factory methods seem to only be there for their own sake.



Arron.

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