Claudenw commented on code in PR #406:
URL:
https://github.com/apache/commons-collections/pull/406#discussion_r1278270734
##########
src/main/java/org/apache/commons/collections4/bloomfilter/CountingBloomFilter.java:
##########
@@ -121,7 +186,7 @@ default boolean merge(final Hasher hasher) {
/**
* Merges the specified index producer into this Bloom filter.
*
- * <p>Specifically: all counts for the indexes identified by the {@code
indexProducer} will be incremented by 1.</p>
+ * <p>Specifically: all cells for the indexes identified by the {@code
indexProducer} will be incremented by 1.</p>
Review Comment:
Is it "required" no, but when working in complex arrangements it mean that
the simply converting to an array does not change the state of the data. In
most cases this is not an issue. The only case where it is an issue is when a
Hasher backed IndexProducer.asArray() is called. In all other cases (I think)
the array either already exists or exists in a different form (BitMaps,
CellProducers). BitMaps and CellProducers always return distinct values in
order.
My plan was to lift the code from BitMapProducer that produces bitMaps and
use it to produce an array of indices from a Hasher.
Perhaps my original comment is not clear. Basically, however the underlying
storage produces the indices is the order and number that will be produced in
the array.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
