From: Arron Bates <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
