home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / object / 4700 < prev    next >
Encoding:
Text File  |  1993-01-04  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!utcsri!torn!nott!bnrgate!bcrka451!bcrki65!sjm
  3. From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
  4. Subject: Re: A Pre-Release FAQ
  5. Message-ID: <1993Jan4.151738.11409@bcrka451.bnr.ca>
  6. Sender: 5E00 Corkstown News Server
  7. Organization: Bell-Northern Research Ltd., Ottawa, Canada
  8. References: <11534@uqcspe.cs.uq.oz.au>> <PCG.93Jan2211415@decb.aber.ac.uk> <11537@uqcspe.cs.uq.oz.au>
  9. Date: Mon, 4 Jan 1993 15:17:38 GMT
  10. Lines: 52
  11.  
  12. In article <11537@uqcspe.cs.uq.oz.au> king@cs.uq.oz.au writes:
  13. >[I won't speculate further on Booch's intentions for not elaborating
  14. >on the distinction between classes and types.  I don't think ridicule
  15. >or support for his actions based on speculation really gets us anywhere.
  16. >The important thing is to clarify our thoughts.]
  17.  
  18. For OOD, the distinction between type and class is not necessary,
  19. perhaps?
  20.  
  21. >
  22. >In <PCG.93Jan2211415@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  23. >
  24. >pcg>On 1 Jan 93 21:56:57 GMT, king@cs.uq.oz.au (Paul King) said:
  25. >
  26. >king> I do not believe there is a lot to be gained by placing too much
  27. >king> emphasis on the difference between type and class (and I have read
  28. >king> numerous articles on this topic - all of which still leave me
  29. >king> unconvinced).
  30. >
  31. >The type of an object then
  32. >is the behaviour of (representation) values it can take on.  The class
  33. >is one way of defining these values.
  34.  
  35. When we equate type with class, we think of things in terms of
  36. discrete, finite types.  This works well for many things.  However, if
  37. by type we mean a classification of objects:  "an object is of type X
  38. if it is allowed to have the following states and the following
  39. behaviour", then we can have a continuum of types from the generic to
  40. the specific, and an infinite number of these continuums.  We obviously
  41. do not implement an infinite number of classes.
  42.  
  43. Inheritance captures the type relationship of general <--> specific.
  44. It does not capture mutability relationships, for example.  As a plastic
  45. cup melts on the stove, it starts out as a cup and ends up as a mess.
  46. From the cup and the environment, we might be able to predict the mess,
  47. but we can't work backwards: there are several starting points that
  48. could have resulted in the same mess.  The object has mutated from one
  49. type into another, and it presumably has undergone a mutation through
  50. an infinite number of types.  
  51.  
  52. I see nothing wrong with equating types and classes while solving many
  53. of today's practical programming problems.  But in general, the mindset
  54. of type == class can restrict our approach to problems.  I think we
  55. need an advance guard always thinking about "what is a type" and "what
  56. is a better way of modelling types?".
  57.  
  58. Stuart
  59.  
  60. --
  61. : Stuart MacMartin                                    email: sjm@bnr.ca      :
  62. : Bell-Northern Research                              phone: (613) 763-5625  :
  63. : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
  64.