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.


Maciej Stachowiak <mstachow@viewlogic.com> writes:

> I don't buy it. Having "integer_list" inherit from "list" is the kind of
> mistake beginning OO-programmers make 

No. What he said was correct.  He talked about emulating genericity by
using polymorphism.  You have an abstract type list and a concrete
type integer and combine them into a integer_list.  To do this the
abstract type must operate on type list_item which is an empty
class. You inherit from type list_item to create an integer_list_item.
After that you can inherit integer_list from list.
The relations are: list /has a/ list_item.  list_item /is a/ <any>
integer_list_item /is a/ list_item.  integer_list /is a/ list.

As for type guards, they are not necessary in eiffel because you can
use "declaration by association".  For example when you pass a
string_list_item to the polymorphic operation list_add_item
the method list_add_item_string gets a parameter that has the type
list_item but not string_list_item (that's because the operation
list_add_item is polymorphic).  In oberon and java you must use a type
guard `(string_list_item)itemī to convert the dynamic type of item
into its static type.  In eiffel you just say that the parameter has
the same type as the class the method belongs to and everything is
fine.


> Actually, Java's built-in array types exhibit the covariance problem
> I described above, one of several glaring design flaws in the Java
> language. 

Guile also uses generic functions and thus has the same problem.  For
example when I pass an integer to environment-unobserve it will simply
crash (at the moment :>).  That's why you must aggressive check the
types of all the parameters. Implicit typing (genericity) is
convenient to the user because he can pass anything he wants.  But I
agree that an explicit type system with polymorphism is better.  (This
is where scheme fails dramatically!)


> So much for the benefits of static typing.

This has nothing to do with static typing.  All generic functions have
this problem.  When you use polymorphism you will have 1 operation with
$n$ functions implementing the operation where each function gets
exactly the types it needs -- or the system will respond with "message
not understood".


Jost

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