Bag (Multiset) Collection

[David Alayachew]

I won't stop you, but remember, you are not the one maintaining the large
number of collection implementations in the JDK. The ones who are may feel
differently. This FAQ gives a good hint of their opinion, even to your
retorts.

On Sat, Apr 20, 2024, 4:44 PM ІП-24 Олександр Ротань <
rotan.olexandr at gmail.com> wrote:

> I agree with the point made in the FAQ about the popularity of such
> problems. That said, I don't think that it is that unpopular to be ignored.
>
> Regarding Map.values(), this is the case, but, In my experience, one of
> the main advantages of using TreeMultiset was O(long n) modification
> complexity. Collection views returned by map, for obvious reasons, forbid
> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
> unpopular requirement, it is at least as popular as TreeSet.
>
> Also, I may not have a full view of how such Bag collections can be
> implemented and used, however, I feel like there could be more to it.
>
> I am not insisting on anything, I just feel that if there is someone (like
> me lol) who is willing to take on full development and integration cycle,
> there aren't much reason to reject such enhancements.
>
> сб, 20 апр. 2024 г. в 23:43, ІП-24 Олександр Ротань <
> rotan.olexandr at gmail.com>:
>
>> I agree with the point made in the FAQ about the popularity of such
>> problems. That said, I don't think that it is that unpopular to be ignored.
>>
>> Regarding Map.values(), this is the case, but, In my experience, one of
>> the main advantages of using TreeMultiset was O(long n) modification
>> complexity. Collection views returned by map, for obvious reasons, forbid
>> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
>> unpopular requirement, it is at least as popular as TreeSet.
>>
>> Also, I may not have a full view of how such Bag collections can be
>> implemented and used, however, I feel like there could be more to it.
>>
>> I am not insisting on anything, I just feel that if there is someone
>> (like me lol) who is willing to take on full development and integration
>> cycle, there aren't much reason to reject such enhancements.
>>
>> сб, 20 апр. 2024 г. в 23:31, David Alayachew <davidalayachew at gmail.com>:
>>
>>> Your Bag suggestion has been asked so frequently that there is an FAQ
>>> entry in the official Java Docs.
>>>
>>>
>>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
>>>
>>> On Sat, Apr 20, 2024 at 4:25 PM ІП-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/8f4b4ac1/attachment.htm>