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. Kinoshita <brunodepau...@yahoo.com.br.invalid> wrote: > 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 < > cla...@xenei.com> wrote: > > 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 > <brunodepau...@yahoo.com.br.invalid> 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 > > 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 a > > draft one). > > Bruno > > > > > > On Thursday, 9 January 2020, 6:32:09 am NZDT, Claude Warren < > > cla...@xenei.com> wrote: > > > > 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&focusedCommentId=17003600 > > ) > > is about the identification of hash implementations. > > > > Currently there are a couple of classes involved: > > > > Hasher interface, has a method that returns a HashFunctionIdentity and a > > method that returns an iterator of enabled bits. There are a couple of > > implementations of Hasher: the DynamicHasher contains buffers that are > > passed to the hash function several times, the StaticHasher contains a > list > > of bits enabled by a hasher for a specific Shape. > > > > HashFunction interface: extends HashFunctionIdentity and adds a method > that > > calls the actual hash function. > > > > HashFunctionIdentity: contains the name of the hash function, the name of > > the provider, the processType (cyclic or iterative), Signedness and a > > signature. > > > > There are places in the code where the actual function is not required > and > > is some use cases would make the implementation difficult or fragile. > > These code places are where the Bloom filter has been built and the > system > > is verifying that two filters used the same hash function. In these > cases > > the comparison is the hashName, processType and Signedness. In cases > where > > the bloom filters are stored in a database retrieval would mean some sort > > of serialization/deserialization of the hash function or ensure that the > > hash function is otherwise available. This is problematic. > > > > The provider was added in a nod to a future factory that would follow the > > JCA pattern and allow implementations of multiple providers. > > > > The signature was added to support a requested quick check. The > signature > > is calculated by calling hashFunction.apply( String.format( "%s-%s-%s", > > getName(), getSignedness(), getProcess() ).getBytes( "UTF-8" ), 0 ). > > > > There were suggestions to create an enum of HashFunctions controlled by > > the Collections. I think that this adds a layer of coordination and > > management on the Collections team that as a team we may not want to take > > on. In addition, it makes it almost impossible for 3rd party users to > > create new hash functions and test them with the library. > > > > I believe the current implementation provides the minimal information > > necessary to determine if two functions are supposed to produce the same > > result. In my mind the signature and provider methods are extra and not > > necessary but desirable. > > > > I think this is a summary of the open discussion. > > > > > > On Wed, Jan 8, 2020 at 2:32 PM Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > Le mer. 8 janv. 2020 à 15:15, Gary Gregory <garydgreg...@gmail.com> 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, variable names, and so on.) I'll proceed with > that > > > > tonight. > > > > > > Design issues were raised on the ML: With no agreement and no opinions > > > other than Claude's and mine, things stayed where they were. > > > > > > Gilles > > > > > > >> [...] > > > > > > --------------------------------------------------------------------- > > > 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 > > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
