@stain. You have correctly identified the code in my repository. The code could be refactored to use streams or we could bring the jena iterator extensions into commons. I had suggested that at one time but there were concerns about conflicts with existing code. Duplication with of functionality was the main concern as I recall.
Claude On Wed, Sep 11, 2019, 09:43 Stian Soiland-Reyes <st...@apache.org> wrote: > On Wed, 11 Sep 2019 18:12:24 +0200, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > The long and short of this is that there is no good unencumbered open > > > source library available at the current time. Myself and several > others, > > > in conversation here at ApacheCon, have expressed interest in creating > such > > > a library. We have fairly mature code that we are willing to > contribute > > > along with code that embodies new thinking in the bloom filter arena > (like > > > proto-bloom filters). We just need a space within the Apache family to > > > host it. The code base seems to small to be a separate project and so > we > > > come to Apache Commons seeking a home. > > > > IMO, a pretty compelling rationale for hosting it at "Commons". > > If people think that [Collections] would be the best home, I'd suggest > > making that component modular; hence unnecessary dependencies > > would be a non-issue. > > Thanks Claude for that brilliant explanation about bloom filter! > (please blog it!) > > At the moment Commons Collections have no runtime dependencies, and only > 3 test-dependencies. > <https://github.com/apache/commons-collections/blob/master/pom.xml#L443> > > So unless the Bloom filter code comes with any new depdendencies seen to > "bloat" rest of Commons, it could fit well in there. > > It would be a new package "bloom" as it's something to use for building > collections rather than directly being a collection - but Collections > already have similar packages for balanced trees, etc. > > > Looking at the code which I suspect is > < > https://github.com/Claudenw/BloomFilter/tree/master/src/main/java/org/xenei/bloomfilter > > > it looks pretty clean, independent and straight forward to read and > understand. > > From Claude's email I see it is it's *use* that needs explanation! > > The only dependencies in that code seem to be within the > org.xenei.bloomfilter.collections package which currently include use of > Jena's extended iterator classes. > > This could probably be refactored, if this package is also to be > included? (those classes would also fit naturally into Collections) > > > -- > Stian Soiland-Reyes > The University of Manchester 🐝 > https://www.esciencelab.org.uk/ > https://orcid.org/0000-0001-9842-9718 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
