Contravariance is generally easiest to understand in the context of aggregation. Consider the parameterized types (looking ahead to Java generics) List<Fruit> and List<Banana>, and variables fruitList and bananaList, and assuming that Banana is a subtype of Fruit. Even though it should be ok in a polymorphic language to assign a value of [static] type Banana to a variable with a type of Fruit, it should be legal to assign a List<Banana> to the variable fruitList. If you did, then static typing would indicate that you could add an Apple to that list, and that would be wrong! It has to do with *static* (i.e. compile-time) typing, which is the kind of typing that makes most Java programs easy to understand.
There are some excellent papers by Luca Cardelli that deal with this in a much more rigorous manner, but they're not fun to read to your friends at parties :-).
In the context of this thread, contravariance is the mathmatical relation between types that exposes the dark side of inheritance. This usually shows up when an "is-a-part-of" relationship is implemented as an "is-a-kind-of" relationship. This results in a subclass that has operations that don't make sense for the superclass, or are just contradictory when applied to the superclass. That's what I'm claiming is the problem with the current implement of form-beans.
-- Dan
Mark Galbreath wrote:
Okay, I'll bite. What is "contravariance?"
Mark
-----Original Message-----
From: Dan Jacobs [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 7:17 AM
Based on the oft misunderstood property of contravariance, I *do* conclude that form-beans should not be subtyped from Java Beans, for the reason that subtypes are never supposed to have fewer behaviors than their supertypes. It's customary in good object-oriented design to use delegation rather than subclassing to use only a selected subset of behaviors from another kind of thing. If Struts is saying that a form-bean should never act like a bean in such-and-such manners, then it follows that form-beans should not be beans. This *is* an architecture issue.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
