commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [Collections] primitive pkg - was "Release potential?"
Date Thu, 22 Aug 2002 17:58:50 GMT
> > <snip all the use cases, good info to have finally, thanks>
> Finally? You mean less than a day after you asked for it? You 
> the stuff mentioned in the initial proposal of moving this 
> code to commons-collections?  

I asked three times, hence "finally".  Yes, I could have searched
the archives, but yes, you could have answered the question.

> > Based on that feedback, it seemed to make sense to eliminate the
> > capacity() et al methods OR to place them in their own interface,
> > to minimize the number of classes in the package. 
> But neither eliminating those methods nor placing them in their own
> interface reduce the number of types in the package.

Um, eliminating the methods would have eliminated the need for
two layers of abstraction, which is what I was going for.  Keeping
the methods means we need both layers, and had to add 3 new classes.
I wasn't trying to reduce, I was trying not to add.  Alas there's
no practical way to not have both layers.

> C) maybe it would be appropriate to take the time to actually 
> understand a body of code before making changes to it or 
> pronouncing its critical design flaws. [10 and others]

Maybe it would be appropriate to not commit an entire package
without documentation, to minimize these misunderstandings.

> (And based on the input from exactly one person with no 
> relation to that code, Paul applies that change [3]. This change 
> has been vetoed [4], but still remains.)

It took time to apply the changes based on the discussion, and I've
already acknowledged that the rush commit was a mistake.  I got too
caught up in rushing for a release, made a mistake, thanks for 
catching it.

> COMPLAINT: Unsigned<Type'>ArrayList should extend <Type>ArrayList, 
> because it "removes an abstract class from the mix" [8][9]
> AND YET: This suggestion is nonsense--it is completely 
> impractical to have the one extend the other--the member variable 
> types are completely different, indeed that's the whole point of 
> the two classes. [10].
> Moreover, this doesn't remove any types from "the mix", there 
> are just as many types as before--in the same distribution of 
> abstract/concrete.

But the resulting abstract class is more general and can 
be extended in more ways, which is what I was going for.

> COMPLAINT: In Paul's opinion, a common interface for
> Unsigned<Type'>ArrayList and <Type>ArrayList is totally 
> unnecessary. Indeed, the capacity methods within ArrayList 
> are totally unnecessary, because Paul's never used them. 
> Never the less, we should add a CapacityList interface 
> and remove the type that plays the direct role of
> Abstract<Type>ArrayList.  Anyone who wants the capacity 
> methods should just downcast, or be content with the 
> generic CapacityList interface [11],[12]
> AND YET: As someone who is actually using the code in 
> question, I assert (again) that I need something that 
> defines that common interface.  And java.util.ArrayList 
> is *the* CapacityList of interest, and will never
> implement that interface, so the utility is questionable. [13]  

Yes, I think this was after I asked you the second time for
use cases.  I couldn't see the need for the capacity() methods,
nor why there'd ever be a method signature like

   sort(AbstractArrayIntList list);

Since you weren't answering the question I had to guess.  I
suggested CapacityList as a generic tool that could *perhaps*
meet your needs, plus others.  Turns out it wasn't a good idea.

However, I will continue to raise ideas for ways of making
Collections stuff more generic, and I fail to see how that's
a bad process.

> Moreover, I'm forced to justify my use of this common interface at
> increasing levels of detail before you guys are willing to accept it
> [7],[10],[13],[14],etc., despite the fact that the initial 
> design doesn't prohibit or make any more difficult any of the 
> changes that you all kept asserting MUST be applied to fix the 
> major design flaws here ([14] again). In fact, the current design is 
> agnostic to those additional layers of abstraction, by intention.

Yes, you are forced to justify your use before it goes in the library.
There are other places in Collections that would have greatly benefited
from peer review before release.

I wanted use cases.  Your answers were things like "IntArrayList
and UnsignedShortArrayList have the exact same API".  Thank you, but
I got that far.  Were you using their capacity() methods interchangeably 
and why, because I couldn't see the need.  You could very well have 
committed public methods that you weren't actually using.  It wouldn't
have been the first time.

And it didn't hurt to double-check.

> And throughout, it's been not so subtly implied that I 
> haven't the least idea of what I'm doing, e.g.,:

I never meant to imply this; if I did, sorry.

> * "I'm hesitant to release an entire new package that seems 
> to need a design phase." [15]

Three people looking at it said "huh?"  I think hesitation
was warranted, and led to a better product.

> * "The API is currently filled with all sorts of wonderful 
> "Wow, this works right now" things that either (a) don't work 
> or (b) can't be usefully extended." [17]

I was speaking to the whole Collections API, not just your
primitives package.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message