[jira] [Comment Edited] (COLLECTIONS-728) BloomFilter contribution

["Gilles Sadowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955217#comment-16955217 ] 

Gilles Sadowski edited comment on COLLECTIONS-728 at 10/19/19 4:51 PM:
-----------------------------------------------------------------------

Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class where the state is provided by a {{BitSet}}?  The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
    private final BitSet state;

    // Constructor(s), builder, and so on.

    // Define methods for which an implementation is required, but
    // nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this implementation will be efficient given the generic passing around of data, with all the boxing and unboxing, insead of operating directly on the {{state}}.
 And, if obviously (?), we'd override the {{default}} methods, why the bloat?

Moreover, as said in the previous comment, the interface forces all implementations to provide a method {{stream()}} with a semantic that might not fit its underlying structure, or even that they would not need at all (say, in order to provide the {{hammingDistance}} property).

This is not to say that the code in {{BloomFilterI2}} is never useful (I don't know) but its place would seem to be in an abstract class, that would e.g. ease prototyping of alternative implementations and test their correctness.  In any case, even if it were actually heading in the right and I fail to see it for some reason, it would still be a refinement that could be left for once we agree on the "bare-bone" functionality.


was (Author: erans):
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class where the state is provided by a {{BitSet}}?  The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
    private final BitSet state;

    // Constructor(s), builder, and so on.

    // Define methods for which an implementation is required, but
    // nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this implementation will be efficient given the generic passing around of data, with all the boxing and unboxing, insead of operating directly on the {{state}}.
 And, if obviously (?), we'd override the {{default}} methods, why the bloat?

Moreover, as said in the previous comment, the interface forces all implementations to provide a method ({{stream()}} with a semantic that might not fit its underlying structure, or even that they would not need at all (say, in order to provide the {{hammingDistance}} property).

This is not to say that the code in {{BloomFilterI2}} is never useful (I don't know) but its place would seem to be in an abstract class, that would e.g. ease prototyping of alternative implementations and test their correctness.  In any case, even if it were actually heading in the right and I fail to see it for some reason, it would still be a refinement that could be left for once we agree on the "bare-bone" functionality.

> 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)