home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2826 < prev    next >
Encoding:
Text File  |  1993-01-27  |  3.0 KB  |  60 lines
  1. Newsgroups: comp.lang.smalltalk
  2. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!uwm.edu!spool.mu.edu!yale.edu!ira.uka.de!Germany.EU.net!donald!hasko
  3. From: hasko@heeg.de (Hasko Heinecke)
  4. Subject: Re: get/set behaviour (was: >>Voluntary method typing)
  5. Message-ID: <1993Jan27.132905.3865@heeg.de>
  6. Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
  7. References: <1993Jan27.001832.10017@cs.uow.edu.au>
  8. Date: Wed, 27 Jan 1993 13:29:05 GMT
  9. Lines: 49
  10.  
  11. In article <1993Jan27.001832.10017@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G Humm) writes:
  12. >
  13. >hasko@heeg.de writes:
  14. >
  15. >In article <1993Jan25.070651.2105@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G >Humm) writes:
  16. >>>>>Of course, this only applies to database-type objects which just have
  17. >>>>>get/set behaviour, but this seems quite a significant subset.
  18. >>>
  19. >>>Are there really any other cases in a pure OO language?
  20. >>
  21. >>Are there really _such_ cases in a pure OO project?
  22. >
  23. >In Smalltalk, objects have named or indexed instance variables. They can be
  24. > assigned references to other objects and the values of those variables
  25. > represent the internal state of the object (only simple types like numbers
  26. > or characters don't have instance variables and still have values; probably
  27. > they had better been separated from objects like e.g. in Eiffel). The only
  28. > way you can change the internal state of an object is assigning another value
  29. > to one of its variables. Reading the value of such a variable gives you the
  30. > reference to another object which allows you to do the same things (assign
  31. > variables or read them). Now you tell me the difference between ``database-type
  32. > objects'' and Smalltalk objects...
  33.  
  34. I didn't talk about Smalltalk in particular (but then, I was... :-) ). Anyway,
  35. in an object-oriented way of thinking, you don't speak of modifying instance
  36. variables but of modifying states. Wether those states are implemented using
  37. one or more of no instance variables at all is a design issue, and in a
  38. perfect world you wouldn't know even the names of the instance variables. Why
  39. bother? That's what member functions/messages are for.
  40.  
  41. The problem is: I can't quite explain the difference between database-type
  42. objects and Smalltalk objects. Maybe, it's just that the words "database-type
  43. objects" imply a certain notion of objects that I don't share, not a real
  44. technical difference. Maybe, it's that we prefer different analysis methods.
  45. Maybe, you are talking about implementation, and I'm talking about analysis
  46. or design. I don't know. All I know is that I don't like the word "database
  47. type objects." N. Wirth said in one lecture about Oberon, object-orientation
  48. is just hierarchical records and procedure variables. In a way, he is right,
  49. but then, he's not. :-)
  50.  
  51. Hasko
  52.  
  53.  
  54.  
  55. -- 
  56. +-------------------------------------------------------+
  57. | Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
  58. | I _never_ mean what I say - and nobody else does...   |
  59. +-------------------------------------------------------+
  60.