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 Mon, 20 May 2002 00:24:29 GMT
>
>
>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?
>


Valid points. DeadObject could be simply used internally, but the class 
returns a null instead. But... I really like your idea that any point an 
item is null, it should be taken as being reset, and a new object be 
built for its place. Quite nice. A good enough reason to lose the dead 
object.


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


The single entry point of the factory is fine, but I just don't like the 
composition of that source file. Including java.util.Collections. It's 
horrible. I'd rather have the other classes there but confined to the 
package. Done widely in other api's. Same thing without the nasty monolith.


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

I know :)
It is much harder when you have to try and get the drum beating on 
someone else's time.
"If an idea is made for an apache project by a non-committer, is it 
really an idea?..."  ;)


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