home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6707 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  4.2 KB
  1. Path: sparky!uunet!utcsri!skule.ecf!torn!nott!cunews!revcan!software.mitel.com!kim!kim
  2. From: kim@Software.Mitel.COM (Kim Letkeman)
  3. Newsgroups: comp.lang.pascal
  4. Subject: Re: BP/TP OOP is missing something...
  5. Message-ID: <KIM.92Nov18085152@kim.Software.Mitel.COM>
  6. Date: 18 Nov 92 13:51:52 GMT
  7. References: <KIM.92Nov16125141@kim.Software.Mitel.COM>
  8.     <1992Nov17.153804.21729@news.clarkson.edu>
  9.     <dmurdoch.282.722020256@mast.queensu.ca> <10773@vice.ICO.TEK.COM>
  10. Sender: kim@Software.Mitel.COM
  11. Organization: MITEL Public Switching, Kanata, Ontario, Canada
  12. Lines: 75
  13. In-reply-to: bobbe@vice.ICO.TEK.COM's message of 17 Nov 92 21:08:27 GMT
  14.  
  15. In article <10773@vice.ICO.TEK.COM> bobbe@vice.ICO.TEK.COM (Robert Beauchaine) writes:
  16.  
  17. |   This whole topic falls under the scope of garbage collection,
  18. |   which is considered by many programmers an extremely important
  19. |   part of a language.  And pascal already does it all the time
  20. |   anyway.  What happens to the local variables allocated on the
  21. |   stack when a function begins or ends?  They are created/destroyed
  22. |   by the compiler, which knows knows exactly how to perform these
  23. |   tasks.
  24.  
  25. Um ... garbage collection is a wholly different concept from local
  26. stack variables. The compiler does not really create or destroy these
  27. variables, it just moves a stack pointer. If you want a variable to be
  28. initialized on entry, you still have to do it yourself. Locals don't
  29. normally require destruction, but if they did you would have to do it
  30. yourself as well.
  31.  
  32. There is no useful analogy between construction and destruction of
  33. atomic (i.e. trivial) variables and objects.
  34.  
  35. |   The only difference between objects and the predefined data types
  36. |   is that *you* have to tell the compiler exactly how to build or
  37. |   get rid of the objects.  You should not have to tell the compiler
  38. |   _when_ to do so.  It seems to me the current object
  39. |   construction/destruction methodology is the departure from the
  40. |   norm.
  41.  
  42. What norm? There lots of competing philosophies and languages and all
  43. are quite different and equally main stream based on number of users.
  44. And only very few have any garbage collection at all.
  45.  
  46. For example, in Actor (a very pure Smalltalk-derived OOP language),
  47. you can simply reuse an object reference and, if that was the last
  48. reference to the previously pointed to object, it is automatically
  49. (read: incrementally) garbage collected for you. The memory is
  50. reclaimed and reused.
  51.  
  52. BUT: if there is a destructor, then you have to call it yourself. I
  53. expect that smalltalk is like this as well.
  54.  
  55. The point being that C++ does not have any real garbage collection at
  56. all. It does not even have reference counting collection, where
  57. destructors are called only if there are no references to them. This
  58. can be built into a base object, but is not truly workable without
  59. serious compiler support. And neither TP nor C++ can provide that
  60. support because of their free-wheeling use of pointers.
  61.  
  62. For further information you should check out Betrand Meyer's Object
  63. Oriented Software Construction. His Eiffel language probably has one
  64. of the better schemes.
  65.  
  66. |   This is exactly why I like the C++ approach.  With automated
  67. |   construction/destruction, operator overloading, etc, objects are
  68. |   much more seamlessly integrated into an application as extensions
  69. |   of the basic data types.  Once the class is properly defined, the
  70. |   programmer never has to consider the objects as anything except
  71. |   predefined atomic stuctures again.
  72.  
  73. As soon as you allow multiple inheritance and such, you have to
  74. potential for a class to break any time a new full build is done. You
  75. can only treat objects as unchanging entities if they are relatively
  76. trivial. Any complex system is constantly evolving and so are its
  77. objects.
  78.  
  79. There's no free lunch. C++ does a lot for you, but you assume a lot of
  80. other burdens for that pleasure. You must now ensure that objects are
  81. compatible with each other in all possible combinations or you'll end
  82. up with complex and hard to debug errors. You must ensure that local
  83. objects are not added to collections or you'll leave dangling
  84. references all over the place. And so on.
  85.  
  86. TP's simplicity is one of its great strengths. And probably one of
  87. the reasons why C++ didn't wipe it out long ago ....
  88. --
  89. Kim Letkeman    kim@Software.Mitel.COM
  90.