[collections] New interface: MultiSet

[Thomas Neidhart <th...@gmail.com>]

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.

Thanks,

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [collections] New interface: MultiSet

[Thomas Neidhart <th...@gmail.com>]

On 06/11/2015 11:18 PM, Matt Benson wrote:
> On Thu, Jun 11, 2015 at 3:37 PM, Thomas Neidhart
> <th...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [collections] New interface: MultiSet

[Matt Benson <gu...@gmail.com>]

On Thu, Jun 11, 2015 at 3:37 PM, Thomas Neidhart
<th...@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?

Matt

>
> Thanks,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org