True, I guess an analysis of the above suggested searches could reveal, in some cases, the sizes of the data and why the dozens or hundreds of cases mentioned above chose to use the flip/inver** methods instead of double storing the datasets. I would think small immutable datasets could be suitable for double storing. For large datasets, the storage requirements might be problematic. For mutable sets, the double manipulations for a putAll (as one example) can become messy.
Cheers, Paul. On Fri, Dec 12, 2025 at 8:19 AM sebb <[email protected]> wrote: > > On Thu, 11 Dec 2025 at 20:57, Paul King <[email protected]> wrote: > > > > Well, I can just give you one user (multiple instances in the > > codebase) that I know of which is why I brought it up. I don't know > > anyone else using Commons Collections in their projects. Many projects > > I am involved in use Groovy which has some nicer workarounds than the > > stream variant I mentioned earlier. So, it's less critical for me, but > > I thought Java users would appreciate the simpler form. > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > quick examples of usage. It goes on to say: > > > > > How to find more examples yourself > > > > > > Use GitHub code search (or grep over downloaded repos) with queries like: > > > > > > Multimaps.invertFrom( > > > invertFrom( + Multimap > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > Those queries will turn up dozens — often hundreds — of usages across OSS. > > > > However, if you know that you will need the inverse, it's not > difficult to build that in parallel. > > Are there any occasions where the inverse has to be built later from > an existing Multimap? > > > Cheers, Paul. > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > <[email protected]> wrote: > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski <[email protected]> > > > wrote: > > > > > > > > Hello. > > > > > > > Isn't it a "chicken-and-egg" question? > > > > Isn't the purpose of a "common" library to implement well-defined and > > > > generally useful functionality, in the hope that it'll incite code > > > > reuse? > > > > Until said functionality is implemented, it obviously cannot be used... > > > > > > No, it isn't. The use case comes first. If you can point to three > > > existing projects that have had to implement this functionality > > > already, and that would be willing to replace their existing code with > > > a common library, then you have a case for implementing it here. > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > worth the effort. > > > > > > -- > > > Elliotte Rusty Harold > > > [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
