On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski <gillese...@gmail.com> wrote:
> Le jeu. 12 sept. 2019 à 17:32, Claude Warren <cla...@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). > Note that plenty of Commons components depend on other Commons components, not just for testing. The most prominent example is Commons DBCP which relies on Commons Pool; in which case duplicating code would be madness ;-) Some Commons components are "higher" level, like Commons Configuration and Commons VFS, and so depend on other Commons components and other 3rd party libraries. It is fair to say that other components we have like Commons Lang and perhaps Commons IO are considered "low" level and do not depend on anything. I would expect Commons Lang to ever depend on anything else (except for testing of course.) Gary 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 <cla...@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 <gillese...@gmail.com > > > > > wrote: > > > > > >> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes <st...@apache.org> > a > > >> écrit : > > >> > > > >> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren <cla...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
