[
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 5:22 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 direction (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)
