commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [collections] - Few more collections for the masses... (impor tant for Struts view objects, maybe other projects)
Date Sun, 19 May 2002 18:23:52 GMT
From: Arron Bates <arron@keyboardmonkey.com>
> > 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.

I thought I'd try an example:

List lazyList = LazyUtils.lazyList(new ArrayList());
// create entries 0 and 1 as 'empty', 2 as an object
Object obj = lazyList.get(2);
// set 1 and 2 to null, leave 0 as 'empty'
lazyList.set(1, null);
lazyList.set(2, null);
// question - what happens here?
Object foo = lazyList.get(0);
Object bar = lazyList.get(1);
Object foobar = lazyList.get(2);

What should foo, bar and foobar return
a) null
b) a newly created object
c) DeadObject

Using my definition  - 'return an object from the factory when the get
method would have returned null or an out of bounds exception' - all three
return a newly created object. null is never returned. In other words,
setting to null is the same as resetting that entry.

Under your original class, get(0) returns a newly created object, but get(1)
and get(2) return null. DeadObject is never returned (except that currently
it is via iterators and subList). My best attempt at a description for this
is 'return an object from the factory if the item doesn't exist in the
collection, or exists in the collection only if a previous get caused this
item to be added'.

Maybe both make sense, but they seem like quite different functionalty not
just something you control with a flag. I think maybe I'm struggling a bit
with the genericity of these collections now. What do others think?

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

The decision to code PredicateUtils as one class is because:
1) This is how java collections do it ( Collections.unmodifiableList() /
Collections.synchronizedList() )
2) Having 8 new classes in the public commons collections API was deemed
undesirable. (In fact there are 18 static nested classes in PredicateUtils!)

The decision to use factory methods is because:
1) This is how java collections do it ( Collections.unmodifiableList() /
Collections.synchronizedList() )
2) It allows the implementation classes to be completely hidden leading to a
compact API.

Stephen

PS. Arron, I am not a committer on collections, so I do not have a 'final
say' here, but I did code PredicateUtils. I can (and have) just commented on
previous discussions and my own opinions ;-)



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