Actually the code I was thinking of is the multi-filter branch. It cleans up some names and simplifies a few things. The collections and storage packages might be best added as examples rather than as mainline code.
In this case we just provide the bloom filter implementation, If we want to provide the container implementation then I think it should probably be modified to accept any SortedSet or NavigatableSet in the constructor. When I return home, next week, I'll take a swipe at moving the packages over to org.apache.commons.collections4.bloomfilter package (unless there is a better package name). We can then look at the entire code donation and decide what changes need to be made before it is accepted. Does this sound like a reasonable approach? Claude On Thu, Sep 12, 2019 at 2:34 AM Gary Gregory <garydgreg...@gmail.com> wrote: > So is the idea to provide wrappers on Sets or a Set implementation? > > Gary > > On Wed, Sep 11, 2019 at 3:54 PM Stian Soiland-Reyes <st...@apache.org> > wrote: > > > I certainly got thinking about streams for those methods using the ancy > > integrators yes. Commons Collection is already on JDK8, so if that is > > sufficient, go for it! > > > > We would need to do IP clearance to bring in the code formally to ASF. It > > should be easy if it is just you who made it under Apache license. > > > > On Wed, 11 Sep 2019, 18:44 Claude Warren, <cla...@xenei.com> wrote: > > > > > @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 > > > > > > > > > > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
