commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gillese...@gmail.com>
Subject Re: New Sub-project Proposal.
Date Thu, 12 Sep 2019 15:42:33 GMT
Le jeu. 12 sept. 2019 à 17:32, Claude Warren <claude@xenei.com> a écrit :
>
> The base code depended on commons-lang3 for building hashes.  Is this
> acceptable or should the hash generation code from lang3 be cut and pasted
> into the classes.  Not sure what the standard is in this project.

There is no "standard".
The least common denominator is "no dependency", not even towards
other components of this "Commons" project (at the cost of duplication
of code and/or API).
The only dependencies are between modules of a component, and on
the condition that all the modules evolve synchronously (same version).

IMHO, we should and could do better (than resort to cut-and-paste).
"Shading" is an alternative.

Gilles

> On Thu, Sep 12, 2019 at 4:14 PM Claude Warren <claude@xenei.com> wrote:
>
> > @Gilles
> >
> > Missed your suggestion about modularity.  Can you point me to the original
> > message or paraphrase it here?
> >
> > Claude
> >
> > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski <gilleseran@gmail.com>
> > wrote:
> >
> >> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes <stain@apache.org>
a
> >> écrit :
> >> >
> >> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren <claude@xenei.com>
> >> wrote:
> >> > > Actually the code I was thinking of is the multi-filter branch.  It
> >> cleans
> >> > > up some names and simplifies a few things.  The collections and
> >> storage
> >> > > packages might be best added as examples rather than as mainline code.
> >> > >
> >> > > In this case we just provide the bloom filter implementation,  If
we
> >> want
> >> > > to provide the container implementation then I think it should
> >> probably be
> >> > > modified to accept any SortedSet or NavigatableSet in the constructor.
> >> > >
> >> > > When I return home, next week, I'll take a swipe at moving the
> >> packages
> >> > > over to org.apache.commons.collections4.bloomfilter package (unless
> >> there
> >> > > is a better package name).  We can then look at the entire code
> >> donation
> >> > > and decide what changes need to be made before it is accepted.
> >> > >
> >> > > Does this sound like a reasonable approach?
> >>
> >> Any comment about my suggestion to make [Collections] modular,
> >> starting with that code ([Collections] is nearing 30k LOC...)?
> >>
> >> Gilles
> >>
> >> > [...]
> >>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message