Bloom filters should not use generics. That has been my stated opinion. They are not like other collections in that you don't get out what you put in. They are collections of hashes so the idea that generics should be used to somehow define what goes in is misleading.
If commons-collections is supposed to be all about putting things into a collection and getting them back out then perhaps bloom filters do not belong here. The only major point of contention is should the package end up looking like the Guice bloom filter package. In my opinion the Guice package is very restrictive. It does not allows for different hashing implementations, it forces a one to one correspondence between an Object and the filter, this makes putting properties of an Object into the filter as separate items difficult if not impossible, and it makes creating partial filters for matching the same still more difficult. Any more complex usage of Bloom filters (e.g. in genomics) will be much harder if not impossible. Going the Guice route also begs the question: Why not just use Guice? The intention of this contribution was a framework that allows the developer to build Bloom filters that a) met the requirements of the application. b) were easy to share between applications. c) could implement most strategies for Bloom filters. The Guice implementation is easy enough to construct with the framework as defined in the current Commons Collections Bloom filter code. And I have no objection to providing a Simple Bloom filter implementation that does that. But doing so should not modify the framework in such a way as to make other usage more difficult. There have been lots of good conversations and lots of improvements since the code was contributed. I have several open source projects that utilized the original code and have been able to easily modify them to use the Commons versions as development and improvements progressed. I would hope to continue to be able to do that as the code moves to a releasable state. As I said above, it may be that commons collections is not the place for Bloom filters. Perhaps they belong in codec or in its own project. I leave that to others to decide. Claude On Wed, Apr 22, 2020 at 12:47 AM Gilles Sadowski <gillese...@gmail.com> wrote: > Hello. > > > > [...] > > > > > > > Attempting to re-awaken this thread. > > > > IMO the bloomfilter package is currently under development. The original > contributor was working through submitting Bloom filter functionality in > parts. My involvement was to ensure the current code that was initially > merged was documented (in javadoc) and functioned as described. This led to > changes of the current functionality and ideas for changes. There were many > ideas in this thread history that were discussed, some agreed and not yet > implemented, some still open for discussion. > > > > Development has stalled and the vision for the final package has not > been completed. At present the bloomfilter added to collections does not > use generics and it has very little to do with java.util.Collection. So is > it even in the remit of commons-collections? > > What would be the alternative(s)? > > > > > I suggested moving to a development branch while the package > functionality is stabilised if any other contributors wish to work on this. > > IIRC, in Commons, branches other than "master" have usually become stale, > unfortunately. They've been rare, and worked on by a single person... > Perhaps somehow mark the feature as not ready, and to be removed from > the release branch (?). > > > I have left development alone as it seems redundant to progress without > a defined scope for the ultimate functionality. > > Do you mean that progress depends on intended usage? > > > > > Opinions on how to proceed? > > I got lost along the way; sorry. > Are there still uncertainties about the "basic" features? > > Regards, > Gilles > > > > > Alex > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
