🚀 go-pugleaf

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
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:

+ 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).

+ 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.

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