Note (might as well make my allegiences clear):
	What I *like* about accessors is that it makes variable access a matter
of message passing. Assignment is one of the few places where Smalltalk
departs from the message passing paradigm (contrast with loops,
conditionals, etc.). I wonder how much of the "ugliness" of using accessors
for variable access simply comes from the fact that it's possible to do it
with assignment. It would be have been interesting, though unfortunate, if,
historically, there had been gramar level conditionals as well as the
message varients in the langauge. I wonder if we'd be arguing about *them*
too! :)
	(Side note 2: the self atVariableIndex: foo put: bar takes care of it,
of course.)

	What I don't like about accessors is that they can be inconvenient to
use and manipulate, as things stand. Auto generation/deletion alone doesn't
cut it :) I suspect that as long as there's a firm and obvious distinction
between variables and methods, folks with tend to *think* in terms of
variables vs. methods, and *that* (I think) makes direct variable access
tempting.

	Hmm. Now I'm curious about temp variables. :) Restricting assignment to
temporary variables would make the temp varible/object variable distinction
clear and allow some conveniences. Hmm.


At 5:15 AM -0400 7/31/99, Alan Lovejoy wrote:

[snip]
>1. Finding all references to an instance variable in a class hierarchy is
>even easier than finding all senders of some message, because there

*Really*? What's the key command. In Squeak it's command-N.

[snip]
>
>2. All classes in Smalltalk can be changed by any programmer.  If an
>instance variable offends thee, thou mayest rename or remove it.  Same
>goes for methods.

True, but isn't a lot of this a matter of convenience? Absent the requisite
tool, I'd much rather tweak an accessor than plod through all the methods
in search of assignments.

The best requisite tool, in this case, is, I suspect, "someone else" :)

>  Similarly, any programmer can add methods to a
>class to access otherwise encapsulated instance varibles--and can
>also use #instVarAt: and #instVarAt:put: to defeat any message-based
>encapsulation of an instance variable.  However, this does not mean
>that one should give up on the attempt to use method-mediated
>encapsulation of state in order to enforce invariants and/or constraints.
>If object encapsulation had no value, then OOP would be pointless.

<sigh/> I just want to say that I think "encapsulation" is a really, really
messy concept. And that most varients are *not* essential properties of OO
systems (Kent Pitman has a very nice article on this.)

[snip]

>7. Whether Andres was wrong or right about direct
>instance variable access, it was not cool to come down
>on him like a ton of bricks.  Andres, on the other hand,
>should have simply questioned why the instance variables
>were not being accessed directly, instead of boldly asserting
>they should be.

My main problems was the notion that we *shouldn't* use accessors in order
to save message sends. *That's* dangerous advice. It's akin to "use big
methods to avoid message sends", or "be aware of the messages which, in
certain classes, are compiles to bytecodes, lik #> on Integer" (note how
the advice has to be framed!). In Python, where the cost of a message send
nee method invokation nee function call is exorbinant, big
functions/methods (or binding the function to a local) *is* standard--and
often good--advice.

But Smalltalk isn't Python.

>We need to treat each other with respect and diplomacy.
>We are ambassadors for Smalltalk, and should act accordingly

I'm not! I wanted to be ambassador to France but couldn't pony up the
donation. In any case, I have been Smalltalkingly long enough to be more
than a "permanant resident" with a slighly wierd visa. Maybe I'll get
naturalized soon!

>when communicating in an open forum, one of whose purposes
>is spreading the Smalltalk gospel.

Eh, I think you're confusing this list with the "EvangeSqueak" list :)

[snip]

>8. Given the above, I would avoid being dogmatic on this
>issue.  I think the fact that so many good Smalltalk programmers
>still access instance variables directly, and that code that commits
>this "sin" has lasted unchanged for so long, should cause one to
>at least question whether or not it's all that sinful.

But do you agree that doing so for the sake of performance without
determining whether it *is* a performance issue in general, or even for the
particular method, is wrongheaded?

[snip]

Cheers,
Bijan Parsia.