Please use accessors!

Alan Lovejoy sourcery at pacbell.net
Sat Jul 31 20:41:23 UTC 1999


> ** Original Sender: Bijan Parsia <bparsia at email.unc.edu>
>[snip]
> 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.

If there is a keyboard shortcut key, the menu offers no hint for it.

It's on the middle button menu for the class pane of the browser, though.
It's called "inst var refs..."--smack dab in the middle of the menu.

> >
> >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" :)

But no! The best requisite tool is the "inst var refs..." pick on the class
pane menu!

> >  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.)

The usual mantra is that an object encapsulates state and behavior.  I agree
that this formula concentrates too much attention on the information hiding,
and not enough on the unification of state and behavior into a single
entity.  Don't get me wrong, I think information hiding is critical to preventing
improper interdependencies.  But the last thing about OO I would give up
would be behavior-state unification.  Information hiding would be next
to last.  You can have OO without information hiding, but not the other
way around.

> >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.

Agreed.

> >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!

Chuckle :-).

I think it is in the best interests of those of us who love Smalltalk to
avoid public relations faux pas when dealing with other participants
in public Smalltalk fora, such as c.l.s or the SquealList.  A little civility
never hurt anyone--and may help Smalltalk.

> >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 :)

<Grin>.  Well, there's more than one type of evangelism.  I tend to dislike
the "It's hellfire and damnation for you if you access instance variables
directly!" kind.

> >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?

Absolutely agreed.

Read Kent Beck on this issue.  I had long battled with extremists on both sides.
When I read Kent's excellent comments, my reaction was "Yeah, what he
said!"

Thank you for your diplomatic reply.

-Alan





More information about the Squeak-dev mailing list