Hello. Le mer. 22 avr. 2020 à 14:56, Gary Gregory <garydgreg...@gmail.com> a écrit : > > 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?
No. > - Does the BF code extend some Commons Collection classes? No. > - Does the BF code reuse Commons Collection utilities? Yes, in class "HasherBloomFilter": import org.apache.commons.collections4.iterators.EmptyIterator; import org.apache.commons.collections4.iterators.IteratorChain; But it also imports from "Commons Codec", in classes "Murmur128x64Cyclic" and "Murmur32x86Iterative": import org.apache.commons.codec.digest.MurmurHash3; > 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? Some info is provided in the "Jdepend" report. Gilles > > 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
