> 2) Subclassing would be more complex. Currently each > Predicate decorator > implementation extends another based on the interface > hierarchy. In order to > continue this, the static nested classes would need to be > package scoped, > not private. Not a big issue, but it should be noted.
I'm even okay with the wrapper classes being package-protected OUTER classes defined in the same source file. Having package-protected classes still gives us a lot of leeway with organizing things, as technically users shouldn't be using package-protected methods and classes. > After a little thought, I think I favour adding Utils to all > of the above. > Results in no clashes with Java, and just involves adding methods to > ListUtils, CollectionUtils and MapUtils. One other consideration is that ListUtils is deprecated. We could always un-deprecate it, of course. I'd want to manually deprecate each method currently in the class though, but that doesn't seem like a big deal. But otherwise, I think having: BagUtils CollectionUtils ComparatorUtils IteratorUtils ListUtils MapUtils PredicateUtils SetUtils TransformerUtils TreeUtils is all good. I'd like FactoryUtils to be SimpleObjectFactoryUtils, which is a very long name but more consistent with the others. > On method names, I agree with your implicit use of yyyedXxx, eg. > filteredMap or predicatedSet This is all sounding dangerously close to consensus! I think this is probably the only civilized conversation on naming conventions I've ever had... :) > BTW: I thought of two more decorator groups - Transform > (already discussed a > little while back) and FixedSize (doesn't allow the size to > change). And I > like the Comparator to Predicate idea. A while back I suggested: public static Set setBackedByMap(Map map); public static SortedSet sortedSetBackByMap(SortedMap map); which would let people use things like LRUMap as a set. Composition patterns galore... -Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
