[
https://issues.apache.org/jira/browse/COLLECTIONS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-819:
--------------------------------------
Description:
[https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L50-L68]
h3.
!https://avatars.githubusercontent.com/u/886334?s=48&v=4|width=24,height=24!
*[aherbert|https://github.com/aherbert]* [on 27
Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970]
This method is only used in testing. What is the use case? Note that
BloomFilter interface cannot merge an IndexProducer. This functionality is only
provided by the constructors for SimpleBloomFilter and SparseBloomFitler. The
method is trivially implemented if a user did want to populate a Bloom filter
with certain indices. But I do not see why they would unless deserialising its
stored representation. Given that we are not supporting any such constructors
for the ArrayCountingBloomFilter (creating and populating at the same time)
this seems like a partial support in the library. Either the serialisation and
deserialisation is better supported, or we drop these methods from the public
API for now.
[https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L104-L119]
h3.
!https://avatars.githubusercontent.com/u/886334?s=48&v=4|width=24,height=24!
*[aherbert|https://github.com/aherbert]* [on 27
Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970]
This method is only used in testing. It is not required for any other
functionality in the API. What is the use case? If this is for serialisation
then the method is trivially performed anyway and the decision should be made
to use this or the bitmap long[] representation depending on the saturation of
the filter. It would be simpler to drop this method.
h3.
was:
h3.
!https://avatars.githubusercontent.com/u/886334?s=48&v=4|width=24,height=24!
*[aherbert|https://github.com/aherbert]* [on 27
Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970]
This method is only used in testing. What is the use case? Note that
BloomFilter interface cannot merge an IndexProducer. This functionality is only
provided by the constructors for SimpleBloomFilter and SparseBloomFitler. The
method is trivially implemented if a user did want to populate a Bloom filter
with certain indices. But I do not see why they would unless deserialising its
stored representation. Given that we are not supporting any such constructors
for the ArrayCountingBloomFilter (creating and populating at the same time)
this seems like a partial support in the library. Either the serialisation and
deserialisation is better supported, or we drop these methods from the public
API for now.
> BloomFilter: Remove IndexProducer.fromArray()
> ---------------------------------------------
>
> Key: COLLECTIONS-819
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-819
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
> Affects Versions: 4.5
> Reporter: Claude Warren
> Priority: Minor
> Labels: bloom-filter
>
> [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L50-L68]
>
> h3.
> !https://avatars.githubusercontent.com/u/886334?s=48&v=4|width=24,height=24!
> *[aherbert|https://github.com/aherbert]* [on 27
> Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970]
> This method is only used in testing. What is the use case? Note that
> BloomFilter interface cannot merge an IndexProducer. This functionality is
> only provided by the constructors for SimpleBloomFilter and
> SparseBloomFitler. The method is trivially implemented if a user did want to
> populate a Bloom filter with certain indices. But I do not see why they would
> unless deserialising its stored representation. Given that we are not
> supporting any such constructors for the ArrayCountingBloomFilter (creating
> and populating at the same time) this seems like a partial support in the
> library. Either the serialisation and deserialisation is better supported, or
> we drop these methods from the public API for now.
>
>
> [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L104-L119]
>
> h3.
> !https://avatars.githubusercontent.com/u/886334?s=48&v=4|width=24,height=24!
> *[aherbert|https://github.com/aherbert]* [on 27
> Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970]
> This method is only used in testing. It is not required for any other
> functionality in the API. What is the use case? If this is for serialisation
> then the method is trivially performed anyway and the decision should be made
> to use this or the bitmap long[] representation depending on the saturation
> of the filter. It would be simpler to drop this method.
> h3.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
