home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / object / 3505 < prev    next >
Encoding:
Text File  |  1992-09-10  |  2.4 KB  |  64 lines

  1. Newsgroups: comp.object
  2. Path: sparky!uunet!munnari.oz.au!metro!graham
  3. From: graham@maths.su.oz.au (Graham Matthews)
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <graham.716171921@galois>
  6. Sender: graham@maths.su.oz.au
  7. Nntp-Posting-Host: galois.maths.su.oz.au
  8. Organization: School of Mathematics and Statistics, University of Sydney
  9. References: <graham.716002888@galois> <1992Sep9.132319.20201@neptune.inf.ethz.ch> <graham.716087001@galois> <1992Sep10.130743.3819@neptune.inf.ethz.ch>
  10. Date: Fri, 11 Sep 1992 00:38:41 GMT
  11. Lines: 51
  12.  
  13. Graham:
  14. >To treat a field as a group however I must
  15. >be able to to throw away an element of my carrier set. Above you
  16. >describe which operations parameterise a group and a field, but you
  17. >make no mention of the carrier set. How does the inheritance system
  18. >know for example which element of the carrier set it must remove to
  19. >view a field as a group?
  20.  
  21. (Philip Santas) writes:
  22. >You do not need to remove anything: Subclasing here is supposed
  23. >to _inherit_ code and not to remove. The above Field,
  24. >inherits operations and axioms from two Groups and it may add some
  25. >more axioms.
  26.  
  27. I am not talking about code, I am talking about carrier sets. The field
  28. viewed as a group has to have a different carrier set. How do I specify
  29. which is the zero element (as this is the one I want to remove).
  30.  
  31. Graham:
  32. >>Say I want to say that all rings
  33. >>are closed and finite (just assume they are). Now do I have to make
  34. >>some class heirarchy like closed_ring < finite_ring < ring, or perhaps
  35. >>I should make finite_ring < closed_ring < ring? Whichever I chose
  36. >>there is an implied order in the class heirarchy that is not in the
  37. >>mathematics.
  38. >Normal _multiple_ subclassing is again enough:
  39. >                   FiniteSet :< Set
  40. >                      Ring :< Set
  41. >   FiniteRing :< FiniteSet  /\   FiniteRing :< Ring
  42. >There is _no_ order in the hierarchy here concerning the class
  43. >FiniteRing.
  44.  
  45. Of course there is an order. You have
  46.  
  47.     FiniteRing < Ring < Set
  48.  
  49. FiniteRing expresses the finite property.
  50. Ring expresses the closed property.
  51.  
  52. Why did you not make the heirarchy
  53.  
  54.     Ring < FiniteSet < Set
  55.  
  56. ie: why did you chose to subclass based on closedness before subclassing
  57. based on finiteness?
  58.  
  59. graham
  60. --
  61. Graham Matthews                 And it's true we are immune
  62. Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
  63. graham@maths.su.oz.au
  64.