Re: [collections] bloom filters comments

2020-01-13 Thread Claude Warren
Gary suggested merging the pull request, Gilles points out there were issues raised on the mailing list, I posted what I think was an accurate summary. What needs to be done to resolve this so that a final decision on the pull request can be made? Claude On Thu, Jan 9, 2020 at 2:57 AM Bruno P.

Re: [collections] bloom filters comments

2020-01-08 Thread Bruno P. Kinoshita
Sorry, I'd read Gary's reply as if there was no PR yet. Reviewed it a bit now, lots of tests! Will play with the code and read the comments and finish the review by the end of the week. Thanks Claude On Thursday, 9 January 2020, 11:20:40 am NZDT, Claude Warren wrote: There is a

Re: [collections] bloom filters comments

2020-01-08 Thread Claude Warren
There is a pull request open: https://github.com/apache/commons-collections/pull/83 On Wed, Jan 8, 2020 at 9:32 PM Bruno P. Kinoshita wrote: > Thanks for the summary Claude. I read some of the messages, but got lost > in the middle of the discussion, and tend to understand problems better if >

Re: [collections] bloom filters comments

2020-01-08 Thread Bruno P. Kinoshita
Thanks for the summary Claude. I read some of the messages, but got lost in the middle of the discussion, and tend to understand problems better if there's some code to read along. And I am used to GitHub/GitLab diff interface. So I agree with Gary that this could be a good time for a PR (maybe

Re: [collections] bloom filters comments

2020-01-08 Thread Claude Warren
I believe the issue (I think history is at https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17003600) is about the identification of hash implementations. Currently there are a couple of classes involved: Hasher

Re: [collections] bloom filters comments

2020-01-08 Thread Gilles Sadowski
Le mer. 8 janv. 2020 à 15:15, Gary Gregory a écrit : > > I think it is time to bring this PR in and make any adjustments within > master beyond that. This will be quicker and simpler than going round and > round for simple things like Javadoc tweaks and small non-functional > changes (formatting,

Re: [collections] bloom filters comments

2020-01-08 Thread Gary Gregory
I think it is time to bring this PR in and make any adjustments within master beyond that. This will be quicker and simpler than going round and round for simple things like Javadoc tweaks and small non-functional changes (formatting, variable names, and so on.) I'll proceed with that tonight.

Re: [collections] bloom filters comments

2019-12-29 Thread Claude Warren
It is currently a sub-class. There was a suggestion to move it outside of the BloomFilter interface. On Sun, Dec 29, 2019 at 3:47 PM Gilles Sadowski wrote: > Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit : > > > > If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter

Re: [collections] bloom filters comments

2019-12-29 Thread Gilles Sadowski
Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit : > > If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter > interface and made a stand-alone class would the name change or is the fact > that it is in the o.a.c.c.bloomfilter package enough? > > I prefer the name Shape to

Re: [collections] bloom filters comments

2019-12-29 Thread Claude Warren
If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter interface and made a stand-alone class would the name change or is the fact that it is in the o.a.c.c.bloomfilter package enough? I prefer the name Shape to BloomFilterShape. Claude On Sat, Dec 28, 2019 at 9:06 AM Claude

Re: [collections] bloom filters comments

2019-12-28 Thread Claude Warren
Once the interface is extracted and reduced to the minimum necessary the following methods are removed: orCardinality() -- we have andCardinality() and xorCardinality() this was included for completeness. isFull() -- true if all the bits in the vector are on. A convenience method used to short

Re: [collections] bloom filters comments

2019-12-27 Thread Gary Gregory
On Fri, Dec 27, 2019 at 11:36 AM Claude Warren wrote: > On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory > wrote: > > > Hi Claude and all: > > > > Here are a couple of comments on the bloom filter PR. > > > > 10,100 ft level comment we do not have to worry about today: Before the > > release, we

Re: [collections] bloom filters comments

2019-12-27 Thread Claude Warren
On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory wrote: > Hi Claude and all: > > Here are a couple of comments on the bloom filter PR. > > 10,100 ft level comment we do not have to worry about today: Before the > release, we might want to split Commons Collection into a multi-module > project and

[collections] bloom filters comments

2019-12-26 Thread Gary Gregory
Hi Claude and all: Here are a couple of comments on the bloom filter PR. 10,100 ft level comment we do not have to worry about today: Before the release, we might want to split Commons Collection into a multi-module project and have the BF code in it own module. The _main_ reason for this is