In Squeak, what is the cost of using an accessor vs. a direct call to the ivar? In VisualAge, for example, the compiler optimizes a send to an accessor and makes it equivalent to a direct access. At least, I believe it is - I'll have to run tests to verify. I think this is true with other dialects as well.

Jeff Odell

----- Original Message ----- From: Carl Gundel morphic@hotmail.com To: squeak@cs.uiuc.edu Sent: Saturday, July 31, 1999 1:03 PM Subject: re: Please use accessors!

...

From: Alan Lovejoy sourcery@pacbell.net Reply-To: squeak@cs.uiuc.edu

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

Thanks for the brain dump Alan! :-)

I understand the pragmatics of this issue well, but I feel compelled to

make

a counterpoint about the above. Code that accesses ivars directly can be brittle. In particular, code which uses both direct access and accessor methods on the same ivars can behave in unpredictable ways. Sometimes

such

code survives for a very long time because it is brittle and hard to understand, and no one wants to touch it for fear of breaking it.

I tend to defer writing code which accesses ivars directly until

performance

tuning time. I wish I never had to write such code because it hurt the maintainability and extensibility of my design, but I live in the real

world

(oh Bah!).

Thanks again!

-Carl

---

Get Free Email and Do More On The Web. Visit http://www.msn.com

At 10:03 AM 7/31/99 -0700, Carl Gundel wrote:

I understand the pragmatics of this issue well, but I feel compelled to make a counterpoint about the above. Code that accesses ivars directly can be brittle. In particular, code which uses both direct access and accessor methods on the same ivars can behave in unpredictable ways. Sometimes such code survives for a very long time because it is brittle and hard to understand, and no one wants to touch it for fear of breaking it.

Code that accesses ivars directly isn't any more brittle or harder to understand than code that uses accessors. If this was so, I could transform my brittle, hard to understand code that accesses ivars directly to non-brittle, easy to understand code that uses accessors in a matter of seconds. I don't claim to be able to do that, but I do claim that I can get rid of direct variable referencing for a particular class in a few seconds.

Anyway, I prefer direct variable referencing. Here are my main reasons why:

*) With direct variable referencing, nobody can write "self instVar anotherInstVar someOtherInstVar yetAnotherInstVar dependents first == self ifTrue: [...]". You may claim that nobody would write such code, but I've seen it too often. It usually comes from someone who has taken the one week Smalltalk course in which they preach that you should always use accessors but forget to teach that it shouldn't be used to navigate through objects.

*) Direct variable referencing is easier to refactor. It is easy to determine every place that a variable is being referenced. Suppose you wanted to remove your variable named "value". If you used direct variable referencing then it is easy to see if anyone references it. However, with accessors there will always be two references so you must determine if those methods are being used. For a variable named "value" you'd most likely have accessors named #value and #value:; determining if anyone sends these messages to your object could be very difficult.

While I expect to have convinced nobody with my reasons, I may have better luck arguing for some improvements in the development environment:

Often I hear arguments that one should use accessors because it is easier to debug since you can put debugging statements in the accessor methods. If you where to use direct variable referencing, then you would have to change a bunch of methods. On the other hand, people in the direct accessor camp often claim that it is harder to debug a program with accessors since you cannot tell by looking at the message send whether this just a simple setter or is doing something more complex. Since probably 95% of all accessors are simple, it is easy to step over something that looks like an accessor only to find that half of your state has changed.

While both of these arguments are valid, I believe that they are really problems with the development environment, not the programs. If the development environment supported break/watchpoints, then one wouldn't have to use accessors to easily add debugging statements. You would enter your watchpoint and the development environment would add the necessary code to all methods.

To solve the accessor debugging problem, I believe that there should be three buttons/menu options on the debugger. One for stepping over the message, one for stepping into a complex method but stepping over accessors, and finally one for stepping into every method. VisualAge treats simple accessors as primitives so it always steps over them. However, there are times when I want to step into the method so I can change the method, but the debugger won't allow me to...

John Brant