home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2839 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.6 KB  |  55 lines
  1. Newsgroups: comp.lang.smalltalk
  2. Path: sparky!uunet!munnari.oz.au!metro!cs.uow.edu.au!humm
  3. From: humm@cs.uow.edu.au (Bernhard G Humm)
  4. Subject: Re: get/set behaviour (was: >>Voluntary method typing)
  5. Message-ID: <1993Jan28.004755.1438@cs.uow.edu.au>
  6. Organization: Dept of Computer Science, Wollongong University, Australia
  7. References: <1993Jan27.001832.10017@cs.uow.edu.au> <1993Jan27.132905.3865@heeg.de> <knight.728144758@cunews>
  8. Date: Thu, 28 Jan 1993 00:47:55 GMT
  9. Lines: 44
  10.  
  11. knight@mrco.carleton.ca (Alan Knight) writes:
  12.  
  13. >The distinction is quite clear from the original post.  It says
  14. >"database-type objects which _just_ have get/set behaviour". Clearly
  15. >objects have a record structure internally, but they also may provide
  16. >a great deal of additional behaviour beyond just setting and getting
  17. >the state of instance variables. I believe the original author was
  18. >referring to objects which do not provide any additional behaviour and
  19. >are thus very much like objects n a database or a "normal" language.
  20.  
  21. No, you missed my point (and I didn't make it too clear I have to admit). 
  22. I am well aware that in an OO language methods can do more that get and 
  23. set internal variables, they can e.g. send messages to other objects. What 
  24. I want to say is:
  25.  
  26. The OO paradigm in its pure form is state based: the state of a system is 
  27. based on the state of all its objects only and the state of an object is 
  28. based on the values of its variables. And the only way of changing variables 
  29. is setting them. So, whatever a method might do its effect has to somehow 
  30. change object state.
  31.  
  32. This is one extreme end of a spectrum. The pure functional paradigm is at 
  33. the other end. In purely functional languages there are no variables at all, 
  34. only parameters to function calls. The ``state'' of a system is determined 
  35. by invocation stacks and the parameters being passed.
  36.  
  37. ``Real programming'' is neither purely OO nor purely functional. But if you 
  38. take a purist's view, the only thing that really counts is get/set, whatever 
  39. a method does in-between.
  40.  
  41.  
  42. >There is also the issue that in an OO language it is not necessary to
  43. >provide these get/set methods, so the internal state of an object may
  44. >not be (entirely) visible to code not part of that object. e.g.
  45. > ...
  46.  
  47. Well, I suppose you are aware that encapsulation (one of the features of OO) 
  48. says that internal object state is NEVER visible to any outside code.
  49.  
  50. -- 
  51. ________________________________________________________
  52.          Bernhard G. Humm   (humm@cs.uow.edu.au)        
  53.        Telecommunications Software Research Centre      
  54. Department of Computer Science, University of Wollongong
  55.