KINDERMA@tubvm.cs.tu-berlin.de (Carsten Kindermann) (12/05/90)
I am interested in constraining a formal generic parameter of a class
definition to more than a single class type.
As an illustration consider the (overly simplified) implementation of a
frame-like knowledge representation system: FRAMEs have SLOTs, and the
value of a SLOT is a list of either FRAMEs, INTEGERs, or STRINGs. The
problem now is to group the three classes FRAME, INTEGER, and STRING
together to get a single class SLOT-VALUE-LIST. SLOT-VALUE-LIST would
then be a descendent of LIST, and might additionally be a sorted list.
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.
I could currently think of two solutions:
(1) Constraining a formal generic parameter by a list of allowable
Class_types.
class SLOT-VALUE-LIST [T-> [FRAME,INTEGER,STRING] ] ...
This seems not to be allowed in Eiffel 2.2, but actually is, I guess,
what I am looking for.
(2) Defining SLOT-VALUES, a common super-class of FRAME, INTEGER,
STRING. Defining this class, however, would make it necessary to define
MYINTEGER (I assume the basic class INTEGER must not be defined as a
descendent of a user-defined class :-) ), but then the INTEGER slot-val-
ues would become objects rather than constants.
Thus, is there any way to do "class grouping" (I think that is how it is
called in the semantic data model area) in Eiffel? If not, how would
you solve the problem? Or maybe, could somebody just give the reasons,
*why* class grouping is not/cannot be included into Eiffel?
Thanks, Carsten Kindermann.
-------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carsten Kindermann
TU Berlin, Projekt KIT-BACK kinderma@tubvm.cs.tu-berlin.de
Sekretariat FR 5-12 or kinderma@db0tui11.BITNET
Franklinstrasse 28/29 Tel.: +49-30/314 24944
D - 1000 Berlin 10 Fax.: +49-30/314 24929rick@tetrauk.UUCP (Rick Jones) (12/06/90)
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