🚀 go-pugleaf

hoelzle@leland.Stanford.EDU (urs hoelzle) writes:

>2.  Here's why you want at least some form of heterogeneous collections:
>	
>	type T = "some type"
>	type SubT = "subtype of T"

>	procedure someProc(c: List[T])

>    I think that you'll agree with me that you'd like to use someProc with
>    a Collection[SubT], especially if someProc just iterates through the
>    list and sends 'foo' -- after all, every SubT "is a" T.  But as soon as
>    Lists are mutable (e.g. define insert(newElem: T)), the type system
>    won't let you do it because List[SubT] is *not* a subtype of List[T].

As someone who hasn't yet completely converted to the object oriented religion,
this has always struck me as using the wrong tool for the job.  I really don't
want a "list of T or subtype of T".  I want a "list of objects that understand
foo".  Once I take that view, I have no problems, at least in the few
statically typed languages that allow this (e.g. Russell, and probably FX from
MIT, and probably Scratchpad II from IBM).  I also don't need to construct
my types in such a way that all types that understand foo are "derived" from
a common supertype;  I can use inheritance purely where it simplifies the
implementation.  And I get full static checking, though elements of the list
will, of course, somehow carry the "foo" function with them.  (In Russell, I
would build a list of pairs <x: T, T: [algebra containing foo]>.)

Hans-J. Boehm
(boehm@xerox.com)