Path: news.daimi.aau.dk!news.uni-c.dk!sunic!trane.uninett.no!nac.no!ifi.uio.no!sics.se!eua.ericsson.se!cnn.exu.ericsson.se!convex!darwin.sura.net!wvnvms!marshall.wvnet.edu!marshall.edu!hathawa2 Newsgroups: comp.object,comp.lang.eiffel,comp.lang.sather,comp.lang.beta Subject: Re: Cows, Hogs & Farms Message-ID: <1995Jan18.135308@hobbit> From: hathawa2@marshall.edu (Mark S. Hathaway) Date: 18 Jan 95 13:53:08 EDT References: <3f9mav$7bf@network.ucsd.edu> <1995Jan17.161207.24578@schbbs.mot.com> Organization: Marshall University Nntp-Posting-Host: frodo.marshall.edu Lines: 86 Xref: news.daimi.aau.dk comp.object:24023 comp.lang.eiffel:7232 comp.lang.sather:1447 comp.lang.beta:226 > In article <1995Jan17.161207.24578@schbbs.mot.com>, > shang@corp.mot.com (David L. Shang) writes: >> In article <3f9mav$7bf@network.ucsd.edu> >> mbk@inls1.ucsd.edu (Matt Kennel) wrote: >> -- Sather >> >> type $HERBIVORE is >> try(food:$PLANT); >> end; >> >> type $HERBIVORE{MYFOOD < $PLANT} is >> try(food:$PLANT); >> eat(food:MYFOOD); >> end; > ... > In general, the second type should be a subtype of the first, as it is > shown in the following Cluster program: > > class HERBIVORE > declare proc try(food:$PLANT); > end; > class HERBIVORE_ON_FOOD is HERBIVORE [MYFOOD <: PLANT] > declare proc eat(food:MYFOOD); > end; >> class COW < $HERBIVORE{GRASS} is >> -- blah blah blah implementation >> end; >> >> class HOG < $HERBIVORE{CORN} is >> -- implementation >> end; >> >> type $IOWA_FARM_ANIMAL > COW,HOG is >> try(food:$PLANT); >> end; > I believe that defining a superclass in terms of a list of exisiting > subclasses is sometimes a useful feature. Cluster-2 does this by > traditional "union" type. >... > class IOWA_FARM_ANIMAL is union {COW, HOG}; > > IOWA_FARM_ANIMAL -- union{COW,HOG} -- is a superclass of COW or HOG, but a > subclass of the LCA of COW and HOG, i.e., a subclass of HERBIVORE[MYFOOD]. >> class IOWAFARM is >> -- has hogs and cows. >> >> attr animals: LIST{$FARM_ANIMAL} >> attr food: LIST{$PLANT}; >> >>... >> end; >> end; >> end; >> end; >> ... > ... There are many ways to use classes as is demonstrated above. One thing which has become clear from reading the thread "Cows, Hogs & Farms" is that there are many ways to use one or more classes to create another class or to use a class to create object(s) at the application level. It would be nice if users of the different languages to which this thread is being posted (and maybe a few other languages like Ada95, Modula-3, C++) would somehow list the different ways "their" language can work with a class to build another or in use in an application. I'm wondering if there should be complete freedom to use classes any way desired, or if there should be a limited set of "operations" that can be done with them for type safety and such. What is the ideal set of "operations" which can be done with a class? Are we going to have to go through a period where these modern OO languages present various mutations from which users will pick and choose (a la Darwin) to find the most fit? Surely there's a better way than that. Mark S. Hathaway