home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6680 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  2.8 KB
  1. Xref: sparky comp.lang.pascal:6680 comp.object:4256
  2. Path: sparky!uunet!olivea!charnel!rat!usc!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!news.ccs.queensu.ca!mast.queensu.ca!dmurdoch
  3. From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
  4. Newsgroups: comp.lang.pascal,comp.object
  5. Subject: Re: BP/TP OOP is missing something...
  6. Message-ID: <dmurdoch.284.722095796@mast.queensu.ca>
  7. Date: 18 Nov 92 14:09:56 GMT
  8. References: <dmurdoch.282.722020256@mast.queensu.ca> <10773@vice.ICO.TEK.COM> <dmurdoch.171.722054313@mast.queensu.ca> <1992Nov18.104536.9985@jyu.fi>
  9. Sender: news@knot.ccs.queensu.ca (Netnews control)
  10. Organization: Queen's University
  11. Lines: 44
  12.  
  13. In article <1992Nov18.104536.9985@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
  14. >There is at least one spot in standard Pascal where automatic initialisation
  15. >happens: file variables (admittedly a murky part of Pascal semantics).
  16. >After _only_ declaring a file variable, it is also initialised to
  17. >a well-defined state such that you cannot do any other operations
  18. >before calling 'reset' or 'rewrite'.
  19.  
  20. That's another difference between TP and standard Pascal then:  in TP, file 
  21. variables remain undefined until you do an Assign (a TP procedure) to set
  22. their state.  
  23.  
  24. >I would guess that good Pascal implementation may also initialise
  25. >pointer variables to NIL so that using them before assignment
  26. >will not cause catastrophic effects.
  27.  
  28. On a PC in "real" mode, NIL is likely the most catastrophic value to 
  29. initialize a pointer to :-).  TP doesn't initialize pointers, but at 
  30. least one TP clone (Pascal+ from Stony Brook) does.
  31.  
  32. >The idea is that all other uses of an object happen between its
  33. >initialisation and the finalisation;  of course you cannot change
  34. >an object after it has been destroyed.  Your matrix example would
  35. >be much easier to do in Simula or C++ than Pascal, because they allow
  36. >variables to be declared even within blocks (not only in function and
  37. >procedure headers), and they allow also initialisation parameters.
  38.  
  39. I agree that Pascal doesn't handle my matrix example well, even with 
  40. conformant arrays.  However, it's really not a problem at all in TP:  just
  41. declare a matrix object, but don't assign a size to it until you know what 
  42. the size will be.  
  43.  
  44. >In any flavour of OO Pascal without such parameters, the constructor
  45. >of a general matrix class (i.e. without fixed dimensions) would most
  46. >naturally create only a "handle" for an actual matrix.
  47.  
  48. This doesn't seem like a very clean solution.  Does it mean that I'd have 
  49. an array without a size after the automatic initialization?  Then I'd have 
  50. to send a size message to it before I could use it?  It sounds to me as 
  51. though the size message is the real initialization; automatic initialization 
  52. doesn't work here, because it doesn't produce a usable object (i.e. 
  53. establish the invariants of the class, as you said).
  54.  
  55. Duncan Murdoch
  56. dmurdoch@mast.queensu.ca
  57.