Well, to be honest, classes not using their own accessors is, IMHO a *frequent* cause of bugs.

But sometimes when you start writing a class you don't realize that you need to have a read trigger or write trigger behavior on an aspect (ie extra code in the accessor/mutator) - so you don't write the accessor and you just muck with the ivar - for awhile.  Later you realize you need to do something else when the ivar is updated so you write an accessor.  

What I would consider a reasonable rule set here:

'self ivarname' and 'self ivarname: value' should work regardless whether the accessor/mutator exists or not.
If the method has been defined - cool so use it - otherwise just access the ivar.  It does add the overhead of requiring a recompile of methods referencing a particular ivar when its accessor/mutator are created/removed.

This would have the effect of eliminating a number of accidental bugs while providing perfectly understandable behavior.

Note that I am not calling for removal of direct ivar access (although you could - it would make people think harder about when to sneak in a value vs use the interface).

On Friday, April 11, 2003, at 12:51  PM, Stephane Ducasse wrote:

The idea of removing direct access is a discussion we got internally for at least two years and I simply wanted to see other opinion that ours. That's why I would like to understand the point made that the Brian (the Slate guy) and Jecel as it seems that they got a lot of experience with that.

stef