🚀 go-pugleaf

In article <1992Nov18.213742.493@afs.com> Michael_Pizolato@afs.com (Michael  
Pizolato) writes:
> A question of philosophy.  Consider the following classes:
> [discussion of direct vs. method access of ivars removed]

I'd like to add to the original by suggesting that even within a class one should only refer to that class' instance variables via methods designated for that purpose, execpt of course in the ivar access methods themselves.  For example:

@interface Mumble:Object
   {
   int value;
   }
- (int)value;
- setValue:(int)number;
- (int)doSometingWith:anotherNumber;
- (int)doSometingWrongWith:anotherNumber;
@end

@implementation Mumble
- (int)value
   {
   return value;
   }

- setValue:(int)number
   {
   value = number;
   return self;
   }

- (int)doSometingWith:anotherNumber
   {
   return [self value] * anotherNumber;
   }

- (int)doSometingWrongWith:anotherNumber
   {
   return value * anotherNumber;
   }
@end

This leads to something of a "class within a class" idea, where there is an inner layer of methods designed to provide access to the instance variables, and other methods that use these access methods to get the values they need.  There can be, however, a blurring of the lines between these two types of methods, for example if methods are implemented that appear to the user of a class to provide access to an instance variable, but which in fact cover a data representation that is implicit in other ivar val
ues.  This kind of method is really neither an ivar access method nor one which does "actual work."

I know this isn't very heavy stuff, but it can become an important consideration when implementing data representations.

-Michael

--
Michael_Pizolato@afs.com
~18 kyu
Q16
NeXTMail appreciated