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] [Commented] (COLLECTIONS-728) BloomFilter contribution
Date Fri, 01 Nov 2019 14:27:00 GMT

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

Mime
View raw message