From: Arron Bates <[EMAIL PROTECTED]> > > > >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.
Great > >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. For OSS work I could be tempted to agree with you (a time implementation I'm looking after uses the package scoped classes approach). But collections (java/apache) seem to like one class. C'est la vie. Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
