[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001889#comment-17001889
]
Gilles Sadowski commented on COLLECTIONS-728:
---------------------------------------------
bq. CachingHasher (from another project) is not possible.
Potentially irrelevant.
Furthermore, I don't get how in principle providing _more_ information (i.e.
the {{HashFunction}} instance itself rather than some of its "properties") can
be an issue.
So if in practice, there is a problem, my opinion is that the design must be
modified without resorting to external code.
bq. communicating with systems that are not java based
Potentially irrelevant.
I've asked the same question about methods like {{isIterative()}}, that also
obviously only make sense in a Java environment.
We had already noticed those non-converging opinions; it seems that we are
repeating arguments. It could be my fault, in case I've missed key points in
your descriptions.
All I think I understand is that application developers need a check that
different parts of a distributed system (both Java and non-Java) use the same
hash function. IIUC, a crude check is OK for you (like {{String}} equality).
But without indications on the capabilities of the non-Java parts of such a
system (e.g. how do they represent {{isIterative()}}?), I'm wary to clutter the
Java API, where the check could actually be made robust through standard Java
practice (e.g. using {{equals(Object)}}).
The simplest way out is Alex's proposal of a "registry", as a plain list of
numbers (and a textual description of the associated "properties").
Even so, I'm maintaining that this is a second-order discussion, as the main
Bloom filter functionality could be fully coded without this fool-proof
checking of the hash function: Indeed, if one of the requirements of the
distributed system is that the hash function is the same, it could simply be
assumed. Sure, it's not robust; but neither is any of the proposed
alternatives.
I understand that you don't agree with this incremental approach; hence the
only way out is to post to the "dev" ML, asking for more knowledgeable (or less
picky ;)) people to have a look at your PR.
I really hope that some solution can be found because it would be nice that
Commons can host this Bloom filter implementation.
> BloomFilter contribution
> ------------------------
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
> Reporter: Claude Warren
> Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
