On 06/11/2015 11:18 PM, Matt Benson wrote: > On Thu, Jun 11, 2015 at 3:37 PM, Thomas Neidhart > <thomas.neidh...@gmail.com> wrote: >> Hi, >> >> I have just committed the first draft of the new interface MultiSet. >> >> What is the idea behind this? >> >> The rationale of this interface (and corresponding implementations) is >> to replace the existing Bag interface, which does violate the Collection >> contract. Actually, I wanted to make the Bag interface compliant to the >> general Collection contract prior to the 4.0 release, but was convinced >> otherwise (which I now consider a big mistake). >> >> Thus, in an attempt to rid commons-collections of such violations, the >> Bag interface shall be deprecated and replaced by a MultiSet, which is >> basically the same, but the interface is cleaned up and a little bit >> enhanced. >> >> Operations that take cardinality into account (as currently the Bag >> does), can be provided as static utility methods in a MultiSetUtils >> class, or optionally, as additional methods in the interface (I am yet >> undecided about that). >> >> It would be nice if some people could review the current interface and >> give feedback. There might still be some typos and the base >> implementation needs to be improved, but it already works as intended. > > I feel a bit weird about the name... why should any kind of "Set" > include > 1 of given element? If you're already entertaining the idea > of using externally defined static utility methods, couldn't all the > "Bag"-style functionality be provided as such against e.g. a List?
@name: the collection javadoc explicitly states the following: Bags or multisets (unordered collections that may contain duplicate elements) should implement this interface directly. see http://docs.oracle.com/javase/7/docs/api/java/util/Collection.html Furthermore, multisets are a pretty common name, e.g. stl c++ does have them, google guava has them, ... Imho, any other name as Bag or MultiSet would be confusing, and we want to replace our Bag interface, so we do not have much choice, I guess. @Bag style list: yes, but it would be inefficient. In fact the set-like operations in CollectionUtils use Lists, although Bags or MultiSets would be more suitable (this is btw. another change I want to introduce in 4.1) Just to list the number of changes of the MultiSet compared to the Bag: * containsAll, removeAll and retainAll violated the Collection contract as they respected cardinality, but these methods can easily be provided as static utility methods * the add method in Bag was not consistent with the Collection contract wrt to the returned boolean. To support the old behavior one can use add(obj, 1) and analyze the returned old count like that: add(obj, 1) == 0 means the obj was not present in the multiset before. * the remove method in Bag removed *all* occurrences from the Bag, while the new MultiSet only removes 1 occurrence, like all Collections. To support the old behavior, the setCount() method has been added, so setCount(obj, 0) is equivalent to the old remove(). Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
