>And simple accessors? Always include them, even if they don't do
>anything but return or access inst vars. A good SmallTalk compiler will
>always inline anyways, and thuse no need to worry about the extra
>message sends. You may need to change them in the future anyways. By
>including them from the start, you won't have to go through an object,
>and change every occurence of 'a :=' to 'self a:'.  It's bitten me on
>the rear a few times.

I just did that in a fairly extensive piece of code recently.  The 
exercise took less than fifteen minutes, and wasn't error-prone at 
all, thanks to the browser's facility for creating a browser for 
"defs of inst var."  I simply went down the list, made the changes 
and had solid working code for the revisions in virtually no time at 
all.  In comparison, it takes about that same amount of time to 
actually create all those accessors at the outset of the code, and is 
disruptive if I have to write new accessors on an "as you go" basis.

While I haven't been hacking Smalltalk seriously for more than a year 
or so now, this is only the first time I have had to do it.  On a 
cost/benefit scale, I don't think this "bitten me on the rear" issue 
weighs terribly heavily.

On the other hand, I don't think any amount of evangelizing on the 
virtues of "always using accessors" will make a hog's breath of 
difference until the "optimization" and "automation" is actually 
accomplished by the compiler and the creation of accessors is 
automated.  People simply won't choose a textually longer, more 
difficult approach that runs almost twice as slowly over a more 
textually straightforward process that requires no human overhead for 
creating all those accessors.

If using accessors is truly desired as a matter of course, I think 
someone need to take the assignment away from us expressly, perhaps 
dropping it into a primitive as has been suggested by some.