Bryce L Nordgren wrote:
Jess Holle <[EMAIL PROTECTED]> wrote on 03/12/2007 12:28:34 PM:
You can always get the current unchecked behavior with
Collection<Object>.

Thing 1:
========
Ummm.  The fact that the above statement is incorrect is precisely why
Java5 generics syntax is dangerous.  Collection<Object> is not considered a
supertype of any other typed Collection, and is therefore not
interchangeable with other typed collections.  (e.g. you can't pass it
around like you would a Collection)

To treat the elements of the collection as you always have, one needs
Collection<Object>, as above.
To treat the collections themselves as you always have, one needs
Collection<?>.

However, if you have a collection which is a supertype of all other
collections, you cannot add any elements to it because the single legal
element type for that collection is unknown.

Thing 2:
========
I don't want the old unchecked behavior.  I want checked behavior,
commons-collections style.  Commons-collections can handle mixed element
types, where every element has bounds on its types.  Generics do not even
contain a way to express "this collection is potentially composed of a
mixture of elements, but every element is guaranteed to be between {Parent}
and {Child} in the class hierarchy".  In order to implement this type of
checked behavior, Java Generics requires that we use the "unchecked"
syntax.  I guess we should call it "implementation-defined type checking".
My plea is not intended to start a war over Java generics, but to beg that
current functionality not be abandonded merely because Java Generics cannot
adequately describe it.
You can express the bounds of <? extends A super B>, right? There's even a more obscure syntax for expressing something that extends multiple classes in cases.

Nothing is perfect, but Java 5 generics seem to strike a good balance. Having constraints to express every nuance would kill usability.

You could always use something like Josh Bloch's heterogeneous type-safe container pattern if you need something more.

--
Jess Holle

Reply via email to