🚀 go-pugleaf

In article <1992Sep3.020352.1872@almserv.uucp>, bnixon@fnma.com (Bill Nixon) writes:
> Just my two cents:
> 
> It seems to me that declaring instance variables in an object's
> interface file somewhat breaks the idea of encapsulation and

/breaks/ is much to harsh a word.  I can't just include Class.h and
go about modifying it's IVs.

> abstraction that object-oriented languages should provide.
> 
> What I have seen done in other language specifications, most recently
> OS/2 SOM, is to provide three interface files (.h) for an object:

I think you meant 3 files - 2 interface files.

> 
> + public - which has all public instance variables and methods.
> Everything defined in this file is directly accessible, even instance
> variables.  This and the "compiled" code for the object is all an
> object user needs to have.
> 
> + private - which has all private instance variables and methods.
> All instance variables and methods declared in this file are limited
> in scope and cannot be directly accessed.  (Normally this is also
> the source file which contains all the code for the methods).

this is basically the source file, correct?  (.c/.m)

> 
> + class - which has all instance variables and methods which can
> be modified via inheritance.  An object subclasser would require
> this file along with the "compiled" code in order to write a subclass of
> the object.
> 
> I am more comfortable living in a private and public environment.
> Basically only put "need to know" data (methods and maybe a few
> instance variables) in the public interface file.  Since most instance
> variables should be private to provide true data abstraction, they would
> not be exposed and this may provide a simplier and "safer" view of the
> object.

I agree that most IVs should be treated as private by subclassers, but
I don't favor enforcing this via extra files, this could be more of a
bookkeeping hassle.  Use of the @public, @private, etc.. would be just
as affective and let you see it (and write it) all in one eyeshot.
(I also don't know for sure whether these are still supported, but I
 suspect they are.)

I don't think the code not knowing of the implementation should necessarily
imply that the programmer isn't knowledgeable of the implementation.

> 
> Bill
> -- 
> email: bnixon@fnma.com (NeXT Mail Okay)
> Bill Nixon, Senior Programmer Analyst, Advanced Technology
> FannieMae, 3900 Wisconsin Ave NW, Washington, DC 22016     (202) 752-5468

-- 
Bill Shirley		|  ``Computer Science is not about computers any 
shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''

-- 
Bill Shirley		|  ``Computer Science is not about computers any 
shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''