This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Polymorphism, genericity, etc.


Michael Vanier wrote:
> 
> 
> When Bertrand Meyer speaks of genericity, he *always* means Genericity 1,
> *not* CLOS-type generic functions, which are a totally different beast.
> His comments about genericity and inheritance effectively amount to this:
> if you have inheritance you can fake genericity (by having an abstract
> "list" class, for instance, and then subclassing it to form an
> "integer_list" class), but the reverse is not true. 

I don't buy it. Having "integer_list" inherit from "list" is the kind of
mistake beginning OO-programmers make (assuming here that a "list" is
a list of some root "object" type which is a supertype of anything). Covariant
formal parameters (as opposed to return types) are forbidden by most languages
because they are __not_ type-safe.

In the case of your example assume I have a function which takes an
argument of type "list" which assumes it can append anything of
type "object" to a "list", including, say, a "string". Now assume I
actually pass it an "integer_list". Oops! I can only add objects of
type "integer" to an object of type "integer_list". Thus "integer_list"
cannot be safely used anywhere a "list" can, and therefore violates
the Liskov Substitution Principle. (This argument assumes a "list"
is mutable but restricting ourselves to immutable data types severely
reduces the interestingness of Meyer's argument).

If Meyer's argument really goes along the lines you described, then
I am shocked that he made such a basic mistake.

> For example, in Java (which has inheritance (polymorphism 2) but no
> generics (genericity 1)), you get around the lack of a parametrized list
> class not by writing a new subclass for each type (which would be
> type-safe), but by using the "list of any object" class, which requires you
> to check types at run-time.

Actually, Java's built-in array types exhibit the covariance problem
I described above, one of several glaring design flaws in the Java
language. In other words, it will allow you to pass a String[] where
an Object[] is expected, and throw run-time type errors if you then
try to assign a non-String to an element of the array.

So much for the benefits of static typing.

 - Maciej

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]