Bag (Multiset) Collection

[ІП-24 Олександр Ротань]

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/a31c04c8/attachment-0001.htm>