Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: A question on generic parameters
Message-ID: <1133@tetrauk.UUCP>
Date: 15 Apr 91 12:17:43 GMT
References: <1203@nikhefh.nikhef.nl>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 58

In article <1203@nikhefh.nikhef.nl> a38@nikhefh.nikhef.nl (James Barr) writes:
>Hi,
>
>please excuse any niavity in this question as I've only spent
>a few days on Betrand Meyers book O.O. Software Construction.
>
>I noticed that you could only do the bare minimum of operations
>on generic class parameters, which seemed a bit limiting.
>In the case of an ordered list class you would need a class
>parameter that could support a comparision function, but there
>seems no way of doing this.
>
>I would very much appreciate an explanation of how you would
>avoid this or if in fact it is a non-problem.

With the current version of Eiffel it is a non-problem, since the language now
supports "constrained genericity", which is in effect what you describe.  This
was introduced in version 2.2 of the language (it is now at version 2.3).  2.2
added a number of syntactical extensions which are not described in OOSC,
making the book a little out of date as far as a thorough description of the
language is concerned (although that is not its purpose).

Constrained genericity works as follows:

class SORTED_LIST [T -> PART_COMPAR]

export ...

inherit TWO_WAY_LIST [T]

feature
	...
end

This is a library class in 2.2 upwards, and requires that the actual generic
parameter of a declaration of SORTED_LIST be a descendant of PART_COMPAR.  So
a client class would use:

	int_list: SORTED_LIST [INTEGER] ;

(The numeric classes inherit from COMPARABLE which inherits from PART_COMPAR).

This allows the code in the generic class to call features of the generic
parameters, since the conformance of the actual parameter has been defined.

Other significant features of the current language not in OOSC (no particular
order, and not exhaustive) are:

	expanded types
	inspect-when (i.e. switch) construct
	safe reverse assignment (i.e. assigning a sub-type to a parent type)
	redefinable prefix and infix operators

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem