Hi All, I'd like to pat ourselves on the back for a smooth ride so far in bringing in new code for a new non-trivial feature :-)
IMO, let's not get hung up on generics for the first cut of the Bloom Filter code. Why? Because generics are erased by the compiler and we can always add them later without break binary compatibility. Now, if adding generics later would require other changes or other changes would be desired with said generics which would end up breaking BC, then we should pause and consider why that is. Any thoughts on that? WRT to 'fitting in' Commons Collection, I would like someone else to reply (please ;-) - Does the BF code implement some Commons Collection interfaces? - Does the BF code extend some Commons Collection classes? - Does the BF code reuse Commons Collection utilities? Tangent: There were UML tools/Maven plugins in the past that could visualize these kinds of relationships, has anyone used any in the recent past? Anything FOSS we could use? Gary On Wed, Apr 22, 2020 at 7:00 AM Claude Warren <cla...@xenei.com> wrote: > 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 >
