On Fri, Dec 12, 2025 at 7:17 AM Paul King <[email protected]> wrote: > > Okay, there doesn't seem to be a lot of interest, but I went ahead and > created the PR anyway: > > https://github.com/apache/commons-collections/pull/665 > > If the decision is to close the PR, at least future users wanting such > functionality might find the discussion and find something useful in > the PR for their own codebases.
Hi All: The feature request and PR look good (after review) and fit in this component's scope IMO. I plan on merging it unless there are valid technical objections. Gary > > Cheers, Paul. > > On Fri, Dec 12, 2025 at 8:54 PM Paul King <[email protected]> wrote: > > > > On Fri, Dec 12, 2025 at 8:39 PM sebb <[email protected]> wrote: > > > > > > 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. > > > > Certainly that would be true for cases where both the normal and the > > inverse maps were always both needed and were created and used in a > > short time span. In the scenarios I am using multimaps, the normal > > data is more long-lived, and the inverse is only needed occasionally > > when the user asks for certain "query" operations. > > > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
