home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2844 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.7 KB  |  56 lines
  1. Newsgroups: comp.lang.smalltalk
  2. Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!usc!cs.utexas.edu!torn!nott!cunews!cunews!knight
  3. From: knight@mrco.carleton.ca (Alan Knight)
  4. Subject: Re: get/set behaviour (was: >>Voluntary method typing)
  5. Message-ID: <knight.728224539@cunews>
  6. Sender: news@cunews.carleton.ca (News Administrator)
  7. Reply-To: knight@mrco.carleton.ca (Alan Knight)
  8. Organization: Carleton University
  9. References: <1993Jan27.001832.10017@cs.uow.edu.au> <1993Jan27.132905.3865@heeg.de> <knight.728144758@cunews> <1993Jan28.004755.1438@cs.uow.edu.au>
  10. Date: Thu, 28 Jan 1993 12:35:39 GMT
  11. Lines: 45
  12.  
  13. In <1993Jan28.004755.1438@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G Humm) writes:
  14.  
  15. >No, you missed my point (and I didn't make it too clear I have to admit). 
  16. >I am well aware that in an OO language methods can do more that get and 
  17. >set internal variables, they can e.g. send messages to other objects. What 
  18. >I want to say is:
  19.  
  20. >The OO paradigm in its pure form is state based: the state of a system is 
  21. >based on the state of all its objects only and the state of an object is 
  22. >based on the values of its variables. And the only way of changing variables 
  23. >is setting them. So, whatever a method might do its effect has to somehow 
  24. >change object state.
  25.  
  26. That's not entirely true. The state of the system is also determined
  27. by what objects exist, and a method can create new objects without
  28. modifying the state of any old ones.  It is also determined by
  29. invocation stacks and parameters just as much as any functional
  30. language.  It is quite conceivable that one could write a program
  31. using an OO language in which no state variables of any object were
  32. ever modified (i.e. set except at creation time).  It has already been
  33. extensively debated whether this is "really OO", and I have no wish to
  34. re-open the topic, but such programs can certainly be written in a
  35. "pure OO" language, making it a question of style.
  36.  
  37. In any case, this is clearly distinct from "database" type objects,
  38. which have no behaviour other than get/set.
  39.  
  40. >>There is also the issue that in an OO language it is not necessary to
  41. >>provide these get/set methods, so the internal state of an object may
  42. >>not be (entirely) visible to code not part of that object. e.g.
  43. >> ...
  44.  
  45. >Well, I suppose you are aware that encapsulation (one of the features of OO) 
  46. >says that internal object state is NEVER visible to any outside code.
  47.  
  48. It's not directly visible, but if you write get/set methods for all
  49. instance variables you have effectively circumvented encapsulation.
  50.  
  51. -- 
  52.  Alan Knight  knight@mrco.carleton.ca  +1 613 225 8812
  53.  The Object People, 885 Meadowlands Dr., Suite 509
  54.  Ottawa, Ontario, Canada, K2C 3N2
  55.  
  56.