Bag (Multiset) Collection

[David Alayachew]

Biggest use case is definitely when creating different histograms from the
same dataset. Our friends in sci-py land spend A LOT of time doing this.
Our R friends also use this frequently.

I can imagine this bag implementation would not just be good for
Collections, but would play well with the Collectors framework, as well as
Gatherers.

On Sat, Apr 20, 2024 at 5:57 PM Holo The Sage Wolf <holo3146 at gmail.com>
wrote:

> By "ordered collection" you mean "unordered collection"?
>
> How common is it to actually use a multiset in general? Of course there
> are use cases, and there are areas in which it is used a lot, but I don't
> believe it is common enough to be part of the std with the one exception of
> concurrent bag.
>
> On Sat, 20 Apr 2024, 23:25 ІП-24 Олександр Ротань, <
> rotan.olexandr at gmail.com> wrote:
>
>> In this letter I would like to express some of my thoughts regarding the
>> potential Multiset interface.
>>
>> I, personally, have encountered a few situations where such an interface
>> could come in handy, mostly when I needed an ordered collection that
>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>> itself should have such a collection in its std library. While it is not a
>> very common problem, there are still a bunch of use cases where such things
>> could come in handy.
>>
>> I am willing to take on development of such thing, but there are a few
>> concerns about Multiset:
>>
>> 1. Is there any other use for this besides ordered collection that
>> permits duplicates? I can't remember anything else from the top of my head.
>>
>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>> class hierarchy, while not being directly connected. I think introducing
>> any other ordered collection will require some refactoring of existing
>> collection interfaces (for example extract SortedCollection from SortedSet,
>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>> code, this would be the right decision, but I feel like this will be a very
>> complex task to accomplish.
>>
>> 3. Maybe there should be few versions of Tree collection (for example,
>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>> have some expirience implementing both, but is it really needed in standard
>> library?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/a96f378b/attachment.htm>