Re: Polymorphism, genericity, etc.

[Michael Vanier <mvanier@bbb.caltech.edu>]

> Mailing-List: contact guile-help@sourceware.cygnus.com; run by ezmlm
> Precedence: bulk
> Sender: guile-owner@sourceware.cygnus.com
> Date: Sat, 24 Jul 1999 20:03:56 -0400
> From: Maciej Stachowiak <mstachow@viewlogic.com>
> X-Accept-Language: en
> Cc: jostobfe@calvados.zrz.TU-Berlin.DE, mstachow@alum.MIT.EDU,
>         silovic@zesoi.fer.hr, chris@tech.com.au, guile@sourceware.cygnus.com
> Content-Type: text/plain; charset=us-ascii
> 
> 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.

Meyer was only saying that it *could* be done, not that it was wise or safe
to do so.  In general, I was thinking more along the lines of having an
abstract class that could be used as the parameter for a sort routine, for
example, not a "list of any object" class.  Maybe I should go get my copy
of OOSC and type in the chapter... :-)

In fact, there are a whole slew of issues involving the interactions
of genericity (in the OO sense) and inheritance similar to the one you
describe.  Meyer has some rules of thumb for preventing them (the
"no polymorphic catcalls" proposal, which I've never managed to wade
through all the way), but I'm sure he's aware of the issues.   


> 
> > 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.
> 

Agreed.  This is one area where Java really stinks.  All the tedium of
static typing and all the type-safety of dynamic typing...

>  - Maciej
>