Bryce L Nordgren wrote:
Thing 2: (snipped)
========
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'm not sure on this last sentence. You can keep the generics to ensure
that the collection is below {Parent}, and add runtime bounds for the
{Child} bound. This does not require use of unchecked collections.
Just trying to clarify...
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.
I would hope not. Keep all this functionality. See
java.util.Collections.CheckedCollection for runtime checking for generic
collections. It is a generic collection that declares what it should
do, with the runtime checking to make sure it does it.
The issue with generics that we will encounter is that Maps and
Collections have typed interfaces now, and so transformed classes have
difficulty in expressing their contents generically, while taking
non-symmetric input arguments - see
https://issues.apache.org/jira/browse/COLLECTIONS-243 for this
interesting side effect. [Utilising a generic collection for these will
currently require that your collection contains a super type of the
transformable input and the transformed contents. This will probably
often require Collection<Object> at the moment.]
Cheers
Stephen K
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
