[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964861#comment-16964861
]
Gilles Sadowski commented on COLLECTIONS-728:
---------------------------------------------
Thanks for explaining again.
I somewhat get the rationale until here:
{quote}True the Hasher could be limited to a StaticHasher and the Shape would
not be needed as the Static Hahser contains the Shape it was built with, but in
the general case a Hasher does not have a Shape.
{quote}
Where it seems that the API could (?) be improved so as to avoid having to pass
{{null}} when the "shape" argument is unused.
{quote}We will always be behind when it comes to implementing new algorithms
using new hash functions.
{quote}
Just _one_ release behind. People who want new features should be around to
provide a patch and help with the release.
{quote}It is better to allow the users in the field to add algorithms as they
see fit.
{quote}
I don't think so; it leads to unnecessary duplication (with a possible
consequence being the "broken" algorithm case which you mention).
{quote}not allowing for addition of others is very limiting.
{quote}
Not really if there is an "active community" (i.e. people willing to work
together towards releasing new features). Once the design is in place, adding
variants of existing features should be straightforward; a new hash function
could be added at time "t0" and a release candidate could be prepared at "t0" +
72 hours (to allow for review), then published another 3 days later.
{quote}they would be unable to add their "broken" hashing to the factory would
be an inhibitor.
{quote}
"Commons" would provide a library of algorithms through its implementation of
the {{Hasher.Factory}} interface, but application developers could define their
own for a particular purpose (such as working around issues of their own ;)).
{quote} why not provide a factory that [...] has the convenience methods to add
hash functions?
{quote}
Because it puts the burden on us to ensure thread-safety (while it is trivially
accomplished with immutable instances).
> 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)
