home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / objectiv / 524 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.1 KB  |  55 lines

  1. Newsgroups: comp.lang.objective-c
  2. Path: sparky!uunet!haven.umd.edu!news.umbc.edu!gmuvax2!bcox
  3. From: bcox@gmuvax2.gmu.edu (Brad Cox)
  4. Subject: Re: instance variable declarations..
  5. Message-ID: <1992Sep8.221554.18393@gmuvax2.gmu.edu>
  6. Organization: George Mason University, Fairfax, Va.
  7. References: <MAS.92Aug30121306@csa.bu.edu> <19385@ector.cs.purdue.edu> <1992Sep2.045715.5803@panix.com>
  8. Date: Tue, 8 Sep 1992 22:15:54 GMT
  9. Lines: 44
  10.  
  11.  
  12. In article <1992Sep2.045715.5803@panix.com> you write:
  13. >In <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:
  14. >Although the quoted passage is incorrectly edited, it is usually NOT
  15. >a good idea to repeat the interface in the implementation.
  16.  
  17. The quoted recommendation in our book reflects the voice of pragmatic
  18. experience, not theoretical necessity. Healthy code is read more than it is
  19. changed/written. And having to read two files, one for data & procedural
  20. interfaces and the other for procedural implementations, really is a
  21. hassle.
  22.  
  23. There was a time when the compiler didn't allow data declarations in the
  24. interface file, but I started putting data declarations in the .m file
  25. enclosed in ifdefs, solely as a readibility aid. The new scheme is much
  26. better because it at least warns if the two are out of sync.
  27.  
  28. Finally, on theoretical grounds alone, data declarations is implementation,
  29. not interface. Putting it in the .h file was a compromise, bowing to the 
  30. compiler and not staying pure to the concept.
  31.  
  32. The very earliest versions of Objective-C (circa 1982) didn't make this
  33. compromise. Everything went into a single file, and the compiler
  34. derived an interface database from that.
  35.  
  36. We eventually retreated from this
  37. posotion when it became painfully obvious that the compiler could never
  38. be omniscient about how to maintain its database, and by hiding this,
  39. users failed to understand the implications of
  40. deleting/renaming/changing class info, especially in multi-person
  41. projects.
  42.  
  43. Brad Cox, Ph.D.
  44. Information Age Consulting
  45. bradcox@infoage.com
  46. 703 968 8229 voice
  47. 703 968 8798 fax
  48.  
  49. Program on Social and Organizational Learning
  50. George Mason University
  51. Fairfax VA 22030
  52. 703 993-1142
  53.  
  54.  
  55.