Should an object always use getters to access its own properties?

I just noticed that the seaside tutorial code always seems to do this - basically the code always says: self valueName. However, the Scriptaculous demos just do: valueName.

I have asked a question about this on the beginners list.

Update:

Randal Schwartz replied - almost immediately - and said

Clearly, position is an instance var, or perhaps a temporary. An instance var
may or may not have accessors, depending on whether it is meant to be tweaked
from the outside. #menuComponent, on the other hand, may be just an accessor,
or it may be a whole pile of code to generate that menu on the fly. At this
point, it doesn't matter.

Whether internal accesses to instance vars should use accessors instead of
direct access is a subject to debate (read: religious war). I hope you
haven't accidentally triggered that thread here. I tend to do the simplest thing that works, and leave it at that.

I totally agree with the simplicity principle. I can see why always accessing properties via getters would result in a consistent experience, i.e. the returned value would be the same whether the inquiring code was internal to the object or another object. However, it seems like more work.

There again, if you have gone to the trouble of establishing getters, perhaps one should use them everywhere. I will have to think about this.

Learning Seaside is really quite confusing

I realised today - whilst rereading the Ajax section of the tutorial that part of the difficulty I was experiencing in learning Seaside was related to the fact that I was trying to understand what it was doing.

Seaside successfully hides all of the javascript required to do Ajax type operations. This means that you can write purely in Smalltalk, and yet deliver Ajax functionality. My problem was that I was trying to interpret the Smalltalk code in a javascript context. in other words, I was trying to work out how the Smalltalk would actually work in the browser. The answer is - it won't. All that happens is the Smalltalk code generates javascript.

On the one hand, understanding what is happening is a useful learning exercise. But, on the other hand, I don't try to understand the bytecode that Squeak generates, so why worry about the javascript? I think the difference is that I understand javascript and therefore naturally want to understand what is happening. I think I have to get over this!

Learning to read smalltalk

Smalltalk has a very simple grammar (it must be true because all the books say so). However, just because the syntax is easy, that doesn't mean it is necessarily easy to understand the code. Take this as an example

renderContentOn: html 
html table: [(self sortBlock 
value: (self filterBlock value: self items)) 
do: [:item | html tableRow: [self renderItemBlock 
value: item 
value: html]]].

I struggled with this for a while, mainly because I was trying to read it left to right. Whereas, what I should have been doing is reading it in unary, binary, keyword order. When you look at it that way the central block becomes more like this:

1. get the list of items
2. filter them by passing the complete item list to the filter block
3. sort the item list that is returned by the filterblock
4. iterate over the sorted list and render them.

It all makes perfect sense, once you get the hang of it.

Things are so much clearer in the morning

I don't know whether this is true of all programming languages, or whether there is something odd about Squeak, but it is amazing how things that made no sense the night before, are suddenly blindingly obvious the next morning!

Objects and messages - that's your lot

I had a problem, yesterday, trying to work out what -> meant. I came across it in the Seaside tutorial and couldn't find any reference to it in my various Squeak books.

Fortunately, the Beginners list offered an immediate answer. It is an infix operate for creating an Association. It is a bit like typing 1 @ 1 would return a Point. The answer is obvious, after the fact, but I was confused at the time.

Thinking about why I was confused made me realise that I still hadn't fully understood the concept of objects and messages, or perhaps to put it more accurately, I hadn't understood the fact that there really isn't anything else in Squeak. So, if what you are looking at is not an object, then it has to be a message. And, if it is a message, try typing it into a method finder window and see what it returns.

Seaside - wow that really is clever stuff

I had held off experimenting with Seaside because I - wrongly - thought that I needed to learn Squeak first. What changed my mind was a brief exchange I had, on the Beginners mailing list, about Morphic, Tweak and other UIs. I suddenly realised that Seaside was - in part - another rendering platform and therefore equally good for learning Squeak with.

Wow, having installed the system, I am really impressed. I will detail the impressive bits as I go along, but if you have been waiting to learn Squeak before tackling seaside, don't hold back.

And, we are back :-)

I decided to give myself a present. I have carved out some time - over the summer - to dive into Squeak. I finally realised that it just wasn't going to happen otherwise. So, this blog will now contain a lot more 'notes to self' and 'ahh, so that's how it works'.