Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Class Grouping
Message-ID: <1048@tetrauk.UUCP>
Date: 6 Dec 90 11:38:48 GMT
References: <90338.181137KINDERMA@DB0TUI11.BITNET>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 52

In article <90338.181137KINDERMA@DB0TUI11.BITNET> KINDERMA@tubvm.cs.tu-berlin.de (Carsten Kindermann) writes:
>
>I am interested in constraining a formal generic parameter of a class
>definition to more than a single class type.
>
> [ ... deleted ... ]
>
>My question thus is:  Is there any way to express in Eiffel that
>SLOT-VALUE-LIST[T] does not hold list elements of any type T, but that T
>must be exactly one of FRAME, INTEGER, STRING.

The main purpose of constrained genericity as I understand it is when the
generic class needs to use features of the actual generic parameter class.
The constraint is required in order to satisfy the type-checking.  E.g. for a
sorted list, the list class must be able to compare two list items, so they
must descend from a class (COMPARABLE) which defines comparison operators.

In your case, what features do FRAME, INTEGER, & STRING have in common that
SLOT_VALUE_LIST must operate on?  If there aren't any, you could declare it as:
SLOT_VALUE_LIST [T -> ANY], although I think that would still give a problem
with INTEGER members.

The concept of SLOT_VALUE as a super-class seems to make more sense, from which
can descend SV_FRAME, SV_STRING, and SV_INT.  The first two can also inherit
from FRAME and STRING respectively, and you _should_ be able to make SV_INT
inherit from the class INT.  This is the library class which defines the
operators for integers, and where INTEGER is theoretically an "expanded INT"
type.  This would mean that SV_INT conforms to INTEGER, but not the reverse.
I'm not sure that 2.2 is totally consistent about the equivalence of INT class
types and INTEGER basic types.

This is a good example of an effective use of multiple inheritance.  It seems
to offer the same facilities as the class grouping you describe with very
little effort.  You can provide the conversions of FRAME to SV_FRAME within the
SLOT_VALUE_LIST class to make things easier by having routines like:

put_frame (f: FRAME), put_string (s: STRING), etc.

Of course if Eiffel supported routine overloading on signature, this would be
even easier, since you could have:

put (f: FRAME), put (s: STRING), etc. in the same class.

I mentioned this idea in a recent post - this is a perfect example of where
it's almost a requirement.  Note also that there is no need for the routine
selection to be based on dynamic type;  static selection is quite adequate.

-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan


Brought to you by Super Global Mega Corp .com