Adam Spitz <aspitz at student.math.uwaterloo.ca> wrote:
	> Personally, I think the loss of being able to use instance variable names
	> as method names more than offsets any increase in apparent simplicity and
	> uniformity.
	
	Interesting. When do you use methods with the same names as instance
	variables? The only time I can think of is when I want to do some sort
	of lazy initialization thing, but then I think that the code
	communicates better if I call the variable something like
	"cachedWobulator" instead of just "wobulator".
	
Well, I think that sticking 'cached' all over the place clutters
the code and makes it less readable.

There are a number of issues here.
One of them concerns the interaction of instance variable names
and method names for the same object.

I *really* don't like the idea that I would never be able to use
'changed' 'copy' 'has' 'logEntry' 'name' 'presenter' 'propertyList' 'size' 
or a handful of other reasonable instance variable names in *any*
descendant of Object without breaking the Object protocol.
(I am particularly fond of 'name' and 'size' and have used 'changed'
and 'propertyList'.)

The other issue concerns the interaction of instance variable names
and method names from *other* protocols.

If I do something as simple as calling an instance variable 'sum'
my class suddently respondsTo: #sum and to that extent can be mistaken
for a Collection.   This change would make #respondsTo: practically
unusable.

	I like the idea that an object is just something that responds to
	messages; it bothers me, at some weird aesthetic level, that accessing
	instance variables is different.

If you want Self, for heaven's sake *use* Self.  I have a copy of Self
on my machine.  It's a neat hack, pushed a long way.  A beautiful piece
of language and implementation research.  But the Self people did the
right thing:  they threw *everything* away and started from scratch.

It seems to me exactly right (at a not so weird aesthetic level)
that accessing instance variables is different from accessing objects,
because instance variables *aren't* objects.

	At a more practical level, it bothers me that I should have to
	think about whether to use "accessor methods" or not.

It's simple:  if you want to provide (*controlled*) access to
an instance variable to other objects, you define access methods,
otherwise you don't.  (Sometimes template methods lead to little
methods which _happen_ to have implementations in some classes that
look like access methods.  I think that's different.)

	And at a completely superficial level, it really bugs me to see
	the word "self" spewed all over my code. ;)
	
Sounds as though what you _really_ want is the "implicit self" feature
of Self.  Self's a fine language, why not move over to it if it's what
you would rather use?