> The plausible reason for using a message to get an instvar is that there *might* be some testing for is nil, or empty etc that makes your code nicer - no seemingly random chunks of code referring to an ivar and having to test it , maybe incorrectly, scattered around.

The term is "lazy-initialization".

> You can make an argument (not completely sure I'd agree with it) that using a message send as your normal style makes this cleaner - for plain instvars you just return them, for ones needing testing you do the testing etc. I guess it's true that having code where in some places you use the direct access and in others you have to use a message in order to make sure the ivar is set up correctly is messy and requires some detailed knowledge of the class. Hmm, yeah, maybe. The downside is the whole bad-C-programmer thing.

Direct vs. lazy initialization is an age-old discussion.  Direct tends
to be best for Smalltalk, with lazy for certain circumstances.

> We could probably do something terribly clever and make the compiler understand that if there is a method named appropriately (simplest choice is "the same as the variable name" but we could set any rule we want) then any place where the direct bytecode would normally be used is replaced by a magic bytecode that actually sends the message. It might even be something the Sista could do magic with. This likely-insane idea would make our code look the same but allow adding a "test and initialise etc" method that just gets used if needed.

You think a new language feature with hidden magic complexity that
makes one's code implicitly do extra things other than what it says
will stop people from creating unnecessary getters and setters and
only write code in a "good style"?

> All this is just fluff though by comparison to not liking raw getter/setter methods being public.

There is nothing inherently wrong with raw getter/setters if they're
necessary, and I think everyone agrees providing them unnecessarily is
a bad thing, however, I don't know anywhere in Squeak where the
problem is rampant enough to warrant such rants.  Note, you have
#instVarNamed:put: to worry about too...   ;)