home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / objectiv / 516 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.2 KB
  1. Path: sparky!uunet!stanford.edu!bcm!aio!shirley
  2. From: shirley@fdr.jsc.nasa.gov (Bill Shirley [CSC])
  3. Newsgroups: comp.lang.objective-c
  4. Subject: Re: instance variable declarations..
  5. Message-ID: <1992Sep3.091617@fdr.jsc.nasa.gov>
  6. Date: 3 Sep 1992 14:16:17 GMT
  7. References: <MAS.92Aug30121306@csa.bu.edu> <19385@ector.cs.purdue.edu> <1992Sep2.045715.5803@panix.com> <1992Sep3.020352.1872@almserv.uucp>
  8. Sender: shirley@fdr (Bill Shirley [CSC])
  9. Organization: Software Technology Branch - NASA/JSC
  10. Lines: 67
  11. Originator: shirley@fdr
  12.  
  13.  
  14. In article <1992Sep3.020352.1872@almserv.uucp>, bnixon@fnma.com (Bill Nixon) writes:
  15. > Just my two cents:
  16. > 
  17. > It seems to me that declaring instance variables in an object's
  18. > interface file somewhat breaks the idea of encapsulation and
  19.  
  20. /breaks/ is much to harsh a word.  I can't just include Class.h and
  21. go about modifying it's IVs.
  22.  
  23. > abstraction that object-oriented languages should provide.
  24. > 
  25. > What I have seen done in other language specifications, most recently
  26. > OS/2 SOM, is to provide three interface files (.h) for an object:
  27.  
  28. I think you meant 3 files - 2 interface files.
  29.  
  30. > 
  31. > + public - which has all public instance variables and methods.
  32. > Everything defined in this file is directly accessible, even instance
  33. > variables.  This and the "compiled" code for the object is all an
  34. > object user needs to have.
  35. > 
  36. > + private - which has all private instance variables and methods.
  37. > All instance variables and methods declared in this file are limited
  38. > in scope and cannot be directly accessed.  (Normally this is also
  39. > the source file which contains all the code for the methods).
  40.  
  41. this is basically the source file, correct?  (.c/.m)
  42.  
  43. > 
  44. > + class - which has all instance variables and methods which can
  45. > be modified via inheritance.  An object subclasser would require
  46. > this file along with the "compiled" code in order to write a subclass of
  47. > the object.
  48. > 
  49. > I am more comfortable living in a private and public environment.
  50. > Basically only put "need to know" data (methods and maybe a few
  51. > instance variables) in the public interface file.  Since most instance
  52. > variables should be private to provide true data abstraction, they would
  53. > not be exposed and this may provide a simplier and "safer" view of the
  54. > object.
  55.  
  56. I agree that most IVs should be treated as private by subclassers, but
  57. I don't favor enforcing this via extra files, this could be more of a
  58. bookkeeping hassle.  Use of the @public, @private, etc.. would be just
  59. as affective and let you see it (and write it) all in one eyeshot.
  60. (I also don't know for sure whether these are still supported, but I
  61.  suspect they are.)
  62.  
  63. I don't think the code not knowing of the implementation should necessarily
  64. imply that the programmer isn't knowledgeable of the implementation.
  65.  
  66. > 
  67. > Bill
  68. > -- 
  69. > email: bnixon@fnma.com (NeXT Mail Okay)
  70. > Bill Nixon, Senior Programmer Analyst, Advanced Technology
  71. > FannieMae, 3900 Wisconsin Ave NW, Washington, DC 22016     (202) 752-5468
  72.  
  73. -- 
  74. Bill Shirley        |  ``Computer Science is not about computers any 
  75. shirley@fdr.jsc.nasa.gov|    more than astronomy is about telescopes.''
  76.  
  77. -- 
  78. Bill Shirley        |  ``Computer Science is not about computers any 
  79. shirley@fdr.jsc.nasa.gov|    more than astronomy is about telescopes.''
  80.