This will be the first in hopefully a series of smaller posts covering common Smalltalk idioms for those not already familiar with Smalltalk style and contrasting to a more well known language for those not already familiar with Smalltalk syntax. Now, for a real expert on the subject of idioms, I'd recommend reading Smalltalk Best Practice Patterns by Kent Beck, but I'll offer up my limited experience on the subject as well, because hey, I have to write about something.

A common thing one wants to do, in any object oriented language, is to initialize an instance variable lazily on first access. In C# this might look like...

public string SearchType { get { if(searchType == null) searchType = "AddressSearch"; return searchType; } set { searchType = value; } }

In Smalltalk, I'd write that like this...

searchType ^searchType ifNil:[searchType := #AddressSearch] searchType: aSymbol searchType := aSymbol

Symbols are often used where strings might be used in languages that lack them. The method #ifNil: when evaluated on a non nil object, simply returns the object itself, but when evaluated on a nil object (nil is a real object in Smalltalk), #ifNil: evaluates the block it was given, and returns the result of the block, which in a block, is always the last expression evaluated, in this case, the value we just set #AddressSearch. So we're setting and returning the value in a single line. Smalltalk has many such conveniences to allow one to write very terse code that's extremely readable.

Now, being object oriented code, there's a chance this class could at some later date be subclassed. If so, the programmer doing so might not like the default you've chosen, and this code offers him no chance to override your decision. If I intended this code to be part of a framework, i.e. subclassed, I'd extract that default value into a method of its own like so...

public string SearchType { get { if(searchType == null) searchType = DefaultSearchType; return searchType; } set { searchType = value; } } protected string DefaultSearchType { get { return "AddressSearch"; } }

In Smalltalk, I'd write that like this...

searchType ^searchType ifNil:[searchType := self defaultSearchType] defaultSearchType ^#AddressSearch searchType: aSymbol searchType := aSymbol

I'd then categorize these in the method categories "accessing" and "accessing defaults". This would be somewhat equivalent to a region in C#, but far better because categories, as far as the code browser is concerned, actually contain those methods, and I can drag and drop methods around to categorize them.

Learning the common category names greatly helps one when browsing existing Smalltalk code, and they act as a form of documentation that you don't really get in other languages. Regions have a similar intent, but their implementation fails to provide the same value.

On thing to always remember when using lazy accessors, is that one can't ever access the instance variable directly from inside the class. You need to always use the accessor method. I've waffled back and forth between direct variable access and lazy initialization several times, but I've finally chosen lazy initialization as my preferred method because it allows one to grow a program better by allowing existing objects to be upgraded on the fly without worrying about uninitialized instance variables. I also enjoy being lazy.