🚀 go-pugleaf

In article <519@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes:
|> From <pallas.669923769@red-dwarf> by pallas@eng.sun.com (Joseph Pallas)
|> quoted by boissier@irisa.fr (franck boissiere) in
|> <1991Mar26.101051.29527@irisa.fr>:
|> 
|> > > |> Sooner or later, opponents of static typing bring out the
|> > > |> heterogeneous collection.  
|> 
|> To handle heterogeneous collections without endangering static
|> typing, use genericity (Eiffel syntax):
|> 
|> 	class COLLECTION [G] ...
|>
|> [More details about Eiffel's generic classes]


Yes, genericity *is* useful (and needed), but it is only a partial
solution.  At the risk of repeating myself, I'll restate the problem
which originally started this discussion:

-------  Hit 'n' if you've already seen this -------------

Suppose you have two classes T and SubT, where SubT is a subtype of T
(in the strict sense of `subtype').  You also have the lists

listA: List[A] 
listB: List[B]

(where List[T] is a generic List including the method insert(elem: T))

Also suppose that there exists a procedure someProc(l: List[A]) which
(among other things) may invoke the function a() on some elements of the
list (a() is defined in A).

Now the problem: List[T] is not a subtype of List[SubT] because of the
insert method (contravariance).  Thus, someProc(listB) is illegal even
though it is perfectly safe since all of its elements are guaranteed to
understand a().  

Summary: instances of generic types are rarely subtypes of each other.
Thus, code which takes an instance of a generic type as an argument cannot
be reused for another instance of this generic type.  This can seriously 
restrict reusability in programs which use many related instances of generic
types, e.g. collections.

------------------------------------------------------------------------------
Urs Hoelzle                 			       hoelzle@cs.stanford.EDU
Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305