Incidentally, I don’t just read other people’s blogs to make nitpicky comments about code ;-), I’ve actually been getting a lot out of your tutorials and explanations these past few days, trying to learn about Seaside, so keep it up, mate, great stuff!

“So if a default is common to all instances, why re-define the value for every instance and add unnecessary overhead?”

A good point, however, thinking about it a bit, I think I value the organization and symmetry better if instance side defaults are defined on the instance side and class side defaults are defined on the class side.

Thinking about it even more, I could easily have the same documentation advantage by having a two method categories for defaults on the class side, instance defaults and class defaults.

I think I’ll have to go back the defaultX style, but on the class side organized via method categories. Appreciate the comment Amos. These are the kinds of little idioms I love so much about good Smalltalk, naming and organization are so important and Smalltalker’s seem to really care enough to make the effort.

commission
commission isNil
ifTrue: [self initializeCommission].
^commission

The reason behind it is the same as adding #yourself to the end of a cascade of messages sent to a collection when you want to assign the result to a variable, even if the particular message prior to #yourself for the particular collection you’re using happens to return the collection. Other collections may do it differently, and somewhere down the track someone else may alter/extend your code to use a different collection.

Don’t get me wrong, I’ve got nothing against Sebastian’s pattern itself, and if the code works for you the way you had it, great - I was just pointing out that certain undocumented assumptions may lead to problems for others. Code is most often written once by one person, but read many times by many different people. ;-)

As for the defaultX methods being on the instance or the class side (note I didn’t say the initializeX methods belong on the class side), of course the class is an object itself (a singleton instance), but it’s also a blueprint for every instance based on it. So if a default is common to all instances, why re-define the value for every instance and add unnecessary overhead? Define it on the class side, add an accessor to return “self class defaultX” on the instance side, and away you go. (If a default was common to all classes, you’d put it on Metaclass. Unless I misunderstood what you meant about a class’ default clashing with an instance’s default?) If the default value is in any way dependent on an instance variable, then of course the defaultX method belongs on the instance side. Otherwise, if it’s “static” (also the Java word for “class side”), I’d put it on the class every time. No big deal for small classes of which there aren’t going to be many instances, but when dealing with larger classes of which there may be hundreds or thousands of instances, a larger memory footprint becomes more important in my experience. And good habits live long, bad habits die hard ;-)

commission
  ^commission ifNil:
      [self initializeCommission.
      commission ]

And I disagree about them belonging on the class side, because the class is an object in its own right, and might have its own defaultX methods. Sebastian’s initialize approach makes this even clearer by extending the initialize pattern to the field level, on the instance side, where it belongs. Having tried Sebastian’s method for a short time, I find I quite like it, and plan on continuing to use it in the future.

initializeCommission
commission := 15.
self changed: #commission

because you want to set up a dependency? Your accessor should therefore look more like

commission
    ^commission ifNil:[
        self initializeCommission.
        commission ]

to return commission explicitly, irrespective of what initializeCommission returns.

I find the defaultX methods a good pattern to follow, though they really belong on the class side, not the instance side since they define behaviour common to the class and not variable from instance to instance. Personally, I tend to avoid lazy initialization unless it’s a rarely-used instance variable with a more-than-trivial memory impact, but that’s more due to preference than to having a definite reason against it.

Great blogs by the way, Ramon, very informative =o)

Your approach does create some symmetry between initializing for the whole class and initializeX for each instance var that I like. It also has the attribute of being more of a command, where my #defaultX’s are a request, I like this as well, it feels more OO and as you say, makes it more amenable to reuse.

My approach requires I know the variable is lazy loaded, not a huge deal, but perhaps less encapsulated than yours. I think I might like #initializeX better than #defaultX, I’ll have to try it on for a bit and see how it feels. What other idioms have you found and adopted?

layout
^ layout ifNil:[self initializeLayout]

initializeLayout
^ layout := self makeLayout

several subclasses implement #makeLayout as they find proper for it’s needs as we already wrote about.

What is new here is that when you need to remake the layout at every refresh of after an updater for instance. As the layout it’s customized at the #makeLayout method, the method #initializeLayout can be used as if it where a #reset and any subclass is guaranteed to have a fresh custom layout. By the way, for syntactic edulcorated rigurosity one can do at superclass:

resetLayout
^ self initializeLayout

Budget>>commission
^ commission ifNil:[self initializeCommission]

Budget>>initializeCommission
^ commission := 15

I’ve seen that from a colleague and adopted it because it allows to refine when you scale design. If I had a subclass of budget with different default commission for this silly example.

I’m sure I have not such imagination to give a real good example right now, but I use it systematically and I have no complains of this practice.