Actually, that's a good point. There are some other considerations behind the long convention...
Technically it's possible for a collection to implement both Set and Bag (getCount() would always return 1 or 0; uniqueSet would return an unmodifiable view of itself)... I'm not saying such an implementation would be useful; but it is legal. If such a SetBag existed, then these methods become ambiguous: Set predicate(Set, Predicate) Bag predicate(Bag, Predicate) Which method does the compiler pick when I invoke PredicateUtils.predicate(new SetBag(), pred)? You can force one method or the other using an explicit cast, but it seems cleaner to have altogether distinct method signatures. Not really much of a consideration given our current API -- like I said, SetBag would be pretty pointless -- but it's conceivable that there may be future Collection interfaces that can be implemented simultaneously. Also, if we wanted to be completely strict, then we'd use "predicatedSet" instead of "predicateSet" -- the JDK wrappers are all specified with an adjective. Also, in another thread, somebody raised the issue of providing unmodifiable wrappers for Bag, SortedBag, Iterator and ListIterator. And MultiMap. I'd also like to see synchronized wrappers for Bag, SortedBag, MultiMap. We already have predicate wrappers and lazy wrappers; the JDK puts all of its wrappers in one monolithic class; what do people think of having just one giant WrapperUtils? It could contain all the predicate, lazy, future unmodifiable and synchronized wrappers. (I think it would still make sense to organize the source into multiple files; but the public API would be just one class). -Paul > -----Original Message----- > From: Michal Plechawski [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 11, 2002 5:18 AM > To: Jakarta Commons Developers List; Stephen Colebourne > Subject: Re: [Collections] ComparableComparator - nulls OK > > > Hello, > > > > What do you think of > > > Set predicate(Set set, Predicate predicate) > > > ? Is that too nondescript? > > > > Actually, there is another factor involved. The > java.utils.Collections class > > uses the long form, eg. > > Collections.unmodifiableMap(Map); > > > > Thus I would prefer the long form. We could agree to differ > from Sun > > however, in which case I would submit a patch to the Predicate > code. > > IMHO Sun has just one argument for leaving the "Map"-like suffix. > It gives a possiblity of all the following to coexist: > > List unmodifiableList(List l) > Set unmodifiableSet(Set s) > Set unmodifiableSet(List l) > > However, I do not see this as a strong argument. But mimicring > the Sun's conventions should be a good idea. > > Michal > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
