This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: Polymorphism, genericity, etc.
- To: Maciej Stachowiak <mstachow@viewlogic.com>
- Subject: Re: Polymorphism, genericity, etc.
- From: Chris Bitmead <chris@tech.com.au>
- Date: Sun, 25 Jul 1999 10:54:47 +1000
- CC: Michael Vanier <mvanier@bbb.caltech.edu>, jostobfe@calvados.zrz.TU-Berlin.DE, mstachow@alum.MIT.EDU, silovic@zesoi.fer.hr, guile@sourceware.cygnus.com
- References: <199907242324.QAA15142@arathorn> <379A546C.6EAC94A8@viewlogic.com>
Maciej Stachowiak wrote:
> 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).
I think Meyer's example if I remember correct (and which went through a
troublesome period of fashion when C++ lacked templates) is that the
item you are putting in a list inherits from list_member. So if you want
to put dogs in a list you change dog to inherit from list_member. And
then you have the problem of getting the object back out again without
casting.
> Covariant
> formal parameters (as opposed to return types) are forbidden by
> most languages
> because they are __not_ type-safe.
In Eiffel they used to be type-safe because global checks were done.
Very ugly in a theoretical sense. I've got a feeling they might have
some other solution now.
> 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.
Yep, if you're going to do type-safe, you need to do it properly. And
when you do it properly the language can get pretty complicated.
--
Chris Bitmead
mailto:chris@tech.com.au