Expand Implemented Interfaces

[sirinath]

Is there a possibility to expand the number of collections interfaces implemented so these classes can be used there any other collection interface is used.

[peter-lawrey]

This is entirely possible. We have a array, queue and map implementation
now. Which collections would you be interested in.

On 12 June 2014 14:08, Suminda Dharmasena notifications@github.com wrote:

Is there a possibility to expand the number of collections interfaces
implemented so these classes can be used there any other collection
interface is used.

—
Reply to this email directly or view it on GitHub
#22.

[sirinath]

I will be interested in seeing all the interfaces under having a backing implementation here. E.g. I have a sortedmap I can pass this to a library accepting sortedmap while using it as a specialized collection in the rest of the code. Also perhaps you have a special treatment for Enum as it can be further optimised than treating it as an object.

Also please get this into MC or some other Maven Repo as it is (pre alpha) if possible so I can just code against the interface and I can update when you make the actual release. (Can add this to the build script and get started with it.)

[leventov]

@sirinath There are really a lot of collection interfaces:

• Map, Set × single key, double key (like Guava's Table) × unique key, multikey (like MultiMap, MultiSet) × simple, sorted by key, insertion-ordered, access-ordered × single value, multivalue (for maps) × "id" key (set with get by special id: int, long or another type object)
• Lists, queues, stacks
• Matrices, Bloom filters, prefix trees, ...

Implementing all this stuff would take man-years. And unfortunately it is very likely that I will stay the only developer of the lib, because entrance threshold of the codegen is very high.

That is why my plan is to implement the simpliest flavour of maps/sets (but to do my best on this) initially and then to look at community response, demands.

[leventov]

@sirinath About publishing preview release - unfortunately we still haven't decided the project name, so we think it would be simplier to wait the first release. Please, wait about a month.

[sirinath]

OK Have you seen fast utils? Also this might give you some ideas.

If you are going to manually write all the code then you are going to kill your self. You definitely need a templating engine to generate the code. Also PRs will mess everything up with some parts being new and the rest not being new. With a template contributors update and what is needed and with DRY in place there is not room for inconsistency.

[leventov]

@sirinath Yes I have looked at most existing libs of this kind: fastutil, Mahout collections, GS collections, HPPC, Trove, Colt.

The generic primitive specialization generator is located here: https://github.com/OpenHFT/UntitledCollectionsProject/tree/6ef5e8dada1f8e406649a321842f1f97d0df2e4b/jpsg . Collections generator is here: https://github.com/OpenHFT/UntitledCollectionsProject/tree/6ef5e8dada1f8e406649a321842f1f97d0df2e4b/lib/impl-generator

[sirinath]

@peter-lawrey perhaps you can extend the use of this generators to generate code for TransFIX against any published FIX Schema.

[sirinath]

May be you can spin out the generator as a separate project.

[leventov]

@sirinath see #6 :)