a38@nikhefh.nikhef.nl (James Barr) (04/11/91)
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. If it is a limitation I thought maybe an extension that could specify the heir of the generic class. So that all operations performable on the heir would also be available on instances of the generic class parameter. eg. class OrderedList [T heir of Ordered] ... deferred class Ordered -- make this an heir of any class/type whose instances/values -- can be ordered. export compare; compare (a,b : Ordered) : Boolean ... Regards, James -- James Barr ............... ...... +31 20-592-5104 ........... .......... James.Barr@nikhef.nl ...... .............. NIKHEF, Kruislaan 409, 1009DB Amsterdam .. ..................
rick@tetrauk.UUCP (Rick Jones) (04/15/91)
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
richieb@bony1.bony.com (Richard Bielak) (04/15/91)
In article <1203@nikhefh.nikhef.nl> a38@nikhefh.nikhef.nl (James Barr) writes: [...] >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. > [...] > >class OrderedList [T heir of Ordered] > ... > >deferred class Ordered > -- make this an heir of any class/type whose instances/values > -- can be ordered. > export compare; > compare (a,b : Ordered) : Boolean > ... > Although not discussed in "Object Oriented Software Construction", Eiffel does support such constructs. This feature is called "constrained genericity". Using the actual syntax, your example would be written as: class OrderedList [ T -> COMPARABLE ] is [...whatever...] Then within this class you could use any routine or attribute from COMPARABLE on things declared with type T. Hope this answers your question. ...richie -- *-----------------------------------------------------------------------------* | Richie Bielak (212)-815-3072 | Programs are like baby squirrels. Once | | Internet: richieb@bony.com | you pick one up and handle it, you can't | | Bang: uunet!bony1!richieb | put it back. The mother won't feed it. |
matt@bacchus.esa.oz (Matt Atterbury) (04/19/91)
In article <1133@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
:
With the current version of Eiffel it is a non-problem, since the language
now supports "constrained genericity", ...
:
class SORTED_LIST [T -> PART_COMPAR]
can you constrain T to more than one superclass (since Eiffel has
multiple inheritance), or do you have to fake a class which inherits
from the relevant superclasses and constrain it to that?
e.g.
class SORT_GRAPHIC_LIST [T -> PART_COMPAR, GRAPHIC]
vs.
define class SORTABLE_GRAPHIC, which inherits from PART_COMPAR and
GRAPHIC, then
class SORT_GRAPHIC_LIST [T -> SORTABLE_GRAPHIC]
regards ...
--
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au] Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au "klaatu barada nikto"
or: ...!uunet!murtoa!bacchus.esa.oz.au!matt "consider this a divorce"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET "life? don't talk to me about life!"