On Thu, 11 Dec 2025 at 23:49, Paul King <[email protected]> wrote: > > 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.
AFAICT, Eclipse Collections flip creates a new Map with the keys and values reversed. So no saving in storage. > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
