commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Sadowski (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (COLLECTIONS-728) BloomFilter contribution
Date Sat, 19 Oct 2019 16:52:00 GMT

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

Mime
View raw message