Xref: utzoo comp.lang.misc:7113 comp.object:2925
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.misc,comp.object
Subject: Re: CHALLENGE: heterogeneous collections
Summary: Combining genericity with inheritance
Message-ID: <519@eiffel.UUCP>
Date: 27 Mar 91 17:24:32 GMT
References: <1991Mar25.220525.11087@leland.Stanford.EDU> <1991Mar26.101051.29527@irisa.fr>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 68

From <pallas.669923769@red-dwarf> by pallas@eng.sun.com (Joseph Pallas)
quoted by boissier@irisa.fr (franck boissiere) in
<1991Mar26.101051.29527@irisa.fr>:

> > |> Sooner or later, opponents of static typing bring out the
> > |> heterogeneous collection.  

To handle heterogeneous collections without endangering static
typing, use genericity (Eiffel syntax):

	class COLLECTION [G] ...

G, the formal generic parameter, describes the arbitrary
type of collection elements. Clients obtain actual collections
by providing some arbitrary type as actual generic parameter for G:

	my_fossil_collection: COLLECTION [FOSSIL]

This is known as unconstrained genericity and works
if no special property is required of collection elements;
in other words, the only operations that class COLLECTION
may apply to entities of type G are those operations which
are defined for all types.

If the elements of the collection must have specific
properties, describe these properties by a class
SPECIFIC and use constrained genericity as follows:

	class SPECIFIC_COLLECTION [G -> SPECIFIC] ...

This means that any actual generic parameter
must be a descendant of SPECIFIC. In other words,
the declaration

	your_stamp_collection: SPECIFIC_COLLECTION [STAMP]

will be valid if and only if STAMP inherits, directly
or indirectly, from SPECIFIC.

As a direct consequence of declaring G as constrained
by SPECIFIC, class SPECIFIC_COLLECTION may manipulate
entities of type G and apply to them any operation
defined in class SPECIFIC. For example, it could
include a routine

	some_operation (s: G) is
		do
			s.spec
		end

where `spec' is a routine declared in class SPECIFIC.

The only practical restriction on clients of such a collection
class, then, is that if they want instances of a certain class
(such as STAMP in the example) to appear in ``specific'' collections,
they must add SPECIFIC to the list of parents of that class.

This is a reasonable requirement: the ability to appear
in such a collection is part of the abstract properties of these
instances.

Of course, the scheme only works if multiple
inheritance is permitted, so that we can add SPECIFIC to the 
list of parents of a class which may already have other
parents, describing other kinds of inherited properties.

-- Bertrand Meyer
bertrand@eiffel.uucp

P.S. After writing this I saw an answer to a message
by Erland Sommarskog; that answer appears to indicate that
the above points may have been made already. I didn't
see Mr. Sommarskog's message itself, however. My apologies
if the above just repeats comments already presented by others.