home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6660 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.9 KB
  1. Path: sparky!uunet!news.tek.com!vice!bobbe
  2. From: bobbe@vice.ICO.TEK.COM (Robert Beauchaine)
  3. Newsgroups: comp.lang.pascal
  4. Subject: Re: BP/TP OOP is missing something...
  5. Message-ID: <10773@vice.ICO.TEK.COM>
  6. Date: 17 Nov 92 21:08:27 GMT
  7. References: <KIM.92Nov16125141@kim.Software.Mitel.COM> <1992Nov17.153804.21729@news.clarkson.edu> <dmurdoch.282.722020256@mast.queensu.ca>
  8. Organization: Tektronix, Inc., Beaverton,  OR.
  9. Lines: 63
  10.  
  11.  
  12.   Well Duncan, it appears that the only thing about TP we agree on
  13.   is that we like using it...
  14.  
  15. In article <dmurdoch.282.722020256@mast.queensu.ca> dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:
  16. >
  17. >This is there in TP, to a very limited extent:  you can have an initialized 
  18. >variable which is an object, and you needn't call the constructor.  It's 
  19. >initialized at program load time, not each time the variable comes into 
  20. >scope.  The destructor is never called.
  21.  
  22.   This is a poor solution, since that variable now exists for
  23.   the entire lifetime of the program, taking up precious data space
  24.   for no reason during the 95+ percent of the time you're not using
  25.   it.
  26.  
  27. >It's pretty unlikely that Borland would make such a fundamental change
  28. >that doesn't add any power to the language.  Your code fragment is exactly 
  29. >equivalent to
  30. >
  31. > var D:DoubleObject;
  32. > begin
  33. >   D.init(1.2);
  34. >   ...
  35. >   D.done;
  36. > end;
  37. >
  38. >Since what you want to do is already possible with nothing more than a 
  39. >couple of extra lines of code, why make a big change to the language?
  40. >
  41.  
  42.   This whole topic falls under the scope of garbage
  43.   collection, which is considered by many programmers an extremely
  44.   important part of a language.  And pascal already does it all the
  45.   time anyway.  What happens to the local variables allocated on the
  46.   stack when a function begins or ends?  They are created/destroyed
  47.   by the compiler, which knows knows exactly how to perform these
  48.   tasks.  The only difference between
  49.   objects and the predefined data types is that *you* have to tell
  50.   the compiler exactly how to build or get rid of the objects.  You
  51.   should not have to tell the compiler _when_ to do so.  It seems to
  52.   me the current object construction/destruction methodology is the
  53.   departure from the norm.
  54.  
  55.   This is exactly why I like the C++ approach.  With automated
  56.   construction/destruction, operator overloading, etc, objects are
  57.   much more seamlessly integrated into an application as extensions
  58.   of the basic data types.  Once the class is properly defined, the
  59.   programmer never has to consider the objects as anything except
  60.   predefined atomic stuctures again.
  61.  
  62. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 
  63.  
  64. Bob Beauchaine bobb@vice.ICO.TEK.COM 
  65.  
  66. "Look, I tried the cat experiment.  On the third trial, the cat was
  67. dead.  On each of the subsequent 413 trials, it remained dead.  Am I
  68. doing something wrong?"
  69.             James Nicoll
  70.  
  71. Q.  How many Heisenbergs does it take to screw in a light bulb?
  72. A.  If you know the number, you don't know where the light bulb is!
  73.  
  74.