From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Thu, 10 Sep 1992 13:07:43 GMT



In article <graham.716087001@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>santas@inf.ethz.ch (Philip Santas) writes:
>>
>>Field((op1,Zero),(op2,One)) :< (Group(op1,Zero) + Group(op2,One))
>>As you see we do not have just one class Ring or Group, but many of them.
>
>I am not sure that this solves my problem. Lets turn this round.
>A car is a vehicle in the sense that to treat a car a vehicle I do
>not have to do anything. 

You have to say at least:

Car :< Vehicle

>To treat a field as a group however I must
>be able to to throw away an element of my carrier set. Above you
>describe which operations parameterise a group and a field, but you
>make no mention of the carrier set. How does the inheritance system
>know for example which element of the carrier set it must remove to
>view a field as a group?

You do not need to remove anything: Subclasing here is supposed
to _inherit_ code and not to remove. The above Field,
inherits operations and axioms from two Groups and it may add some
more axioms.

On the other hand, the parameters in the functr, tell to the system
from which particular Group to inherit. Notice that a set can be
a group, or ring or whatever with respect to more than one operations.
It is up to the parameters to define this relationship.

But after you have called the functor, the class you get
has no parameters; the class is ready, constructed, unique.

>>The above are functors which construct these classes.
>>You can say describe them as parameterised classes, but they are
>>actually functions which return classes.
>
>And now we are getting closer to the point. These functors are maps
>between "types". They are relationships between types describing
>how one type may be views as another.

Almost: One has to make the distinction between functors
and coercions: Functors _construct_ new _types_, while coercions
_transform__elements_ from one type to another.

(I do not like the word mapping, since every function is a mapping,
but this misses the point that every function is an instance 
of a certain type).

>>Really, here _normal_ multiple subclassing does a pretty good job.
>Perhaps we have a difference of taste here.

It is not a matter of taste: Actually I do not see any other form of
relationship here except normal subclassing.

>Say I want to say that all rings
>are closed and finite (just assume they are). Now do I have to make
>some class heirarchy like closed_ring < finite_ring < ring, or perhaps
>I should make finite_ring < closed_ring < ring? Whichever I chose
>there is an implied order in the class heirarchy that is not in the
>mathematics.

Normal _multiple_ subclassing is again enough:

                   FiniteSet :< Set
                      Ring :< Set
   FiniteRing :< FiniteSet  /\   FiniteRing :< Ring

There is _no_ order in the hierarchy here concerning the class
FiniteRing.


Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
     



Newsgroups: comp.object