🚀 go-pugleaf

In article <MAS.92Aug30121306@csa.bu.edu>, mas@csa.bu.edu writes:
> Why is it that instance variables are declared in an object's
> @interface portion (interface file) while an object's method's are in
> the @implementation portion (implementation file)?

(dumb) Reason #1: Because if you don't put the instance variables in
  the @interface, and you put them in the @implementation portion,
  you will probably get errors from your compiler.
  (mine says: 'inconsistent instance variable specification', and
   claims that the instance variables used in the methods in the
   @implementation section are 'undeclared').

Reason #2: Brad Cox designed Objective-C to require the instance
  variables in the @interface; putting them in the @implemenation
  is just for convenience.

  From _Object_Oriented_Programming:_An_Evolutionary_Approach_, 
  Brad J. Cox and Andrew J. Novobilski, 2nd ed., page 89:
  (quoted without permission)

        I find it convenient to provide all superclass and instance
      variable information in both files, even though Objective-C
      only requires this information in the interface file.  If you
      adhere to the first philosophy, you may omit the superclass
      and instance variable information from your implementation
      file, and will therefore need to read source code across two
      files.  By duplicating the information about instance variables
      and superclass information, it is available in the same file
      with the methods.  When the information is present in both
      files, the compiler requires that it match exactly.        


> I had kind of pictured the interface file as akin to a prototypes
> file, while the implementation file contained the actual code.  Since
> instance variables are private data, it seems to me that they should
> be declared in the implementation file (along with the methods) rather
> than the interface file.

Subclasses of a class need to have the instance variable information
for the class as well, so the @interface section is the most convenient
place to put them.

I (partially) feel the way you do, though.  There are sometimes 
instance variables in a class which a subclass should not modify,
either because consistancy between several variables is necessary,
or the variable is a relatively complex data structure (eg, a linked
list) of which you don't want to document the internals, or is
simply private (in some way of thinking) to the class and subclasses
should not need to "know" about it (in the way that methods not listed
in the interface file are not "known", but are inherited as usual).
Where necessary, the class should provide methods, which the subclass
should use, to access these types of instance variables.

Indexed instance variables may be the solution here; I have never
attempted to use that facility.  It seems to be more trouble than
it is really worth.

Christopher Kane
kane@cs.purdue.edu

In <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:


>In article <MAS.92Aug30121306@csa.bu.edu>, mas@csa.bu.edu writes:
>> Why is it that instance variables are declared in an object's
>> @interface portion (interface file) while an object's method's are in
>> the @implementation portion (implementation file)?

>(dumb) Reason #1: Because if you don't put the instance variables in
>  the @interface, and you put them in the @implementation portion,
>  you will probably get errors from your compiler.
>  (mine says: 'inconsistent instance variable specification', and
>   claims that the instance variables used in the methods in the
>   @implementation section are 'undeclared').

Note that the interface is the definitive place for instance variables.
You cannot declare instance variables in the implementation which are
not declared in the interface. Allowing the instance variables and
other declarations in the implementation was originally intended to
facilitate automatic conversion from older versions of OC which
did not have an interface and implementation section per se.

>Reason #2: Brad Cox designed Objective-C to require the instance
>  variables in the @interface; putting them in the @implemenation
>  is just for convenience.

>  From _Object_Oriented_Programming:_An_Evolutionary_Approach_, 
>  Brad J. Cox and Andrew J. Novobilski, 2nd ed., page 89:
>  (quoted without permission)

>        I find it convenient to provide all superclass and instance
>      variable information in both files, even though Objective-C
>      only requires this information in the interface file.  If you
>      adhere to the first philosophy, you may omit the superclass
>      and instance variable information from your implementation
>      file, and will therefore need to read source code across two
>      files.  By duplicating the information about instance variables
>      and superclass information, it is available in the same file
>      with the methods.  When the information is present in both
>      files, the compiler requires that it match exactly.        

Although the quoted passage is incorrectly edited, it is usually NOT
a good idea to repeat the interface in the implementation. You will
constantly be required to maintain both copies. While this may seem
like a good idea (since you are FORCED to edit the implementation) it
is probably not necessary if you are fairly disciplined.

>> I had kind of pictured the interface file as akin to a prototypes
>> file, while the implementation file contained the actual code.  Since
>> instance variables are private data, it seems to me that they should
>> be declared in the implementation file (along with the methods) rather
>> than the interface file.

>Subclasses of a class need to have the instance variable information
>for the class as well, so the @interface section is the most convenient
>place to put them.

Absolutely the only place to put them.

>I (partially) feel the way you do, though.  There are sometimes 
>instance variables in a class which a subclass should not modify,
>either because consistancy between several variables is necessary,
>or the variable is a relatively complex data structure (eg, a linked
>list) of which you don't want to document the internals, or is
>simply private (in some way of thinking) to the class and subclasses
>should not need to "know" about it (in the way that methods not listed
>in the interface file are not "known", but are inherited as usual).
>Where necessary, the class should provide methods, which the subclass
>should use, to access these types of instance variables.

Once I again, I must agree. An early version of the OC compiler supported
the keywords: "@public", "@private", and "@readonly" between decls
in the interface. I'm not sure if this is still supported in the released
version, I'll have to check.

These keywords allowed the class designer to designate instance variables
or methods as private to the class implementation. Although the interface
is included by the subclass, the IVs marked private would not be in scope.

Providing method access to class behavior is the best way to go; since you
can override the method in subclasses, but not an instance variable.

>Indexed instance variables may be the solution here; I have never
>attempted to use that facility.  It seems to be more trouble than
>it is really worth.

Indexed instance variables are wonderful when used correctly. In most cases
though, you can get by with an encapsulated array. Using IIVs does not really
protect your data either, since a client class can acces them with "at:".

IIVs are really just additional storeage locations which are allocated after
the named instance variables, and accessed primarily with the "at:" methods.

Christopher Caserio

In article <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:
>
|In article <MAS.92Aug30121306@csa.bu.edu>, mas@csa.bu.edu writes:
|> Why is it that instance variables are declared in an object's
|> @interface portion (interface file) while an object's method's are in
|> the @implementation portion (implementation file)?
...
|Reason #2: Brad Cox designed Objective-C to require the instance
|  variables in the @interface; putting them in the @implemenation
|  is just for convenience.
...
While Brad was responsible for the original Objective-C, it is my
understanding that he had little to do with the modern Objective-C
language (Objective-C 4.0 and above).

|
|  From _Object_Oriented_Programming:_An_Evolutionary_Approach_, 
|  Brad J. Cox and Andrew J. Novobilski, 2nd ed., page 89:
|  (quoted without permission)
|
|        I find it convenient to provide all superclass and instance
|      variable information in both files, even though Objective-C
|      only requires this information in the interface file.  If you
|      adhere to the first philosophy, you may omit the superclass
|      and instance variable information from your implementation
|      file, and will therefore need to read source code across two
|      files.  By duplicating the information about instance variables
|      and superclass information, it is available in the same file
|      with the methods.  When the information is present in both
|      files, the compiler requires that it match exactly.        
|
|
...

Of course, a decent editor would make the superclass and instance
variable information in the interface file look as if it were in the
implementation file and make it available for editing. 

...
|Subclasses of a class need to have the instance variable information
|for the class as well, so the @interface section is the most convenient
|place to put them.
|
|I (partially) feel the way you do, though.  There are sometimes 
|instance variables in a class which a subclass should not modify,
|either because consistancy between several variables is necessary,
|or the variable is a relatively complex data structure (eg, a linked
|list) of which you don't want to document the internals, or is
|simply private (in some way of thinking) to the class and subclasses
|should not need to "know" about it (in the way that methods not listed
|in the interface file are not "known", but are inherited as usual).
|Where necessary, the class should provide methods, which the subclass
|should use, to access these types of instance variables.
...
agreed.

|
|Indexed instance variables may be the solution here; I have never
|attempted to use that facility.  It seems to be more trouble than
|it is really worth.
...
No, indexed instance variable are used for array-like appendages to
objects. 

|
|Christopher Kane
|kane@cs.purdue.edu


-- 
Kenneth Lerman                  ...!uunet!casey!gaboon!seltd!lerman
Systems Essentials Limited                            (203)426-4430
55 Main Street
Newtown, CT 06470

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

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

In article <1992Sep2.045715.5803@panix.com> you write:
>In <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:
>Although the quoted passage is incorrectly edited, it is usually NOT
>a good idea to repeat the interface in the implementation.

The quoted recommendation in our book reflects the voice of pragmatic
experience, not theoretical necessity. Healthy code is read more than it is
changed/written. And having to read two files, one for data & procedural
interfaces and the other for procedural implementations, really is a
hassle.

There was a time when the compiler didn't allow data declarations in the
interface file, but I started putting data declarations in the .m file
enclosed in ifdefs, solely as a readibility aid. The new scheme is much
better because it at least warns if the two are out of sync.

Finally, on theoretical grounds alone, data declarations is implementation,
not interface. Putting it in the .h file was a compromise, bowing to the 
compiler and not staying pure to the concept.

The very earliest versions of Objective-C (circa 1982) didn't make this
compromise. Everything went into a single file, and the compiler
derived an interface database from that.

We eventually retreated from this
posotion when it became painfully obvious that the compiler could never
be omniscient about how to maintain its database, and by hiding this,
users failed to understand the implications of
deleting/renaming/changing class info, especially in multi-person
projects.

Brad Cox, Ph.D.
Information Age Consulting
bradcox@infoage.com
703 968 8229 voice
703 968 8798 fax

Program on Social and Organizational Learning
George Mason University
Fairfax VA 22030
703 993-1142

bcox@gmuvax2.gmu.edu (Brad Cox) writes:
>In article <1992Sep2.045715.5803@panix.com> you write:
>>In <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:
>>Although the quoted passage is incorrectly edited, it is usually NOT
>>a good idea to repeat the interface in the implementation.

>The quoted recommendation in our book reflects the voice of pragmatic
>experience, not theoretical necessity. Healthy code is read more than it is
>changed/written. And having to read two files, one for data & procedural
>interfaces and the other for procedural implementations, really is a
>hassle.

When you've taken this step, repeating the instance variable
declarations in the .m file, it comes into your mind that this is
unnecessary redundancy.  What do you need in a  .h  file
additionally to the instance variable and method declarations?

First there is the #import directive for the superclass header
file. If you have all the directories containing the header files
in your cc's -I path then you can extract the directive out of
the class definition:

	@implementation MyObject:Object

in the .m file becomes to

	#import <Object.h>
	@interface MyObject:Object

in the .h file. Next thing are additional typedefs or #defines.
In my early ObjC programs I have used some of them. But as time
went by they showed up as the weak points in my program, where I
couldn't reuse code and design, where the polymorphism was
broken. So I've actually removed all of them. But I've left two
or three #defines for some hardwired implemention restrictions
(oh, blame me:-().

Thus I need a way to write these statements in the .m file. The
easiest solution is the #pragma directive. And because I'm
working with NeXTstep, where  the  header  files  are  in
subdirectories, I use this technique for the superclass header
file too:

	#pragma .h #import <objc/Object.h>
	#pragma .h #define MAXADDRESS 5
	@implementation MyObject:Object

in the .m file becomes to

	#import <objc/Object.h>
	#define MAXADDRESS 5
	@interface MyObject:Object

in the .h file. And I use a simple awk-script to extract the .h
file from the .m file. If you want to see this script then let me
know.

Stefan
-- 
Stefan Krause                          Kiel, Germany
stef@tpki.toppoint.de                  Tel.(voice) +49 431 335022