About KCP and automatic initialize

Richard Staehli rastaehli at mac.com
Fri Sep 12 18:50:20 UTC 2003


Avi's description of initialization conventions looks like a 
combination of design patterns.

On Vendredi, sep 12, 2003, at 04:55 Europe/Zurich, Avi Bryant wrote:
> The only formal conventions I know of for dealing with this problem
> actually come not from Smalltalk but from the NeXT FoundationKit for
> Objective-C.
>
> There is some description of these conventions in the documentation of
> #init and #new on NSObject:
>
> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
> ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/init
>
> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
> ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/new

(My definitions for these patterns; apologies if someone else has used 
these names in a different way.)

Pattern 1:  Canonical Initializer

Problem:  How to establish a single method for an object that 
initializes to a well defined state.  Users with minimal training 
should be able to discover this method and use it reliably to 
initialize the object.

Solution:  Require that every object have a method named with the 
prefix 'initCanonical' and taking a set of arguments that completely 
define the state of the object.  If the object inherits state from a 
superclass, the 'initCanonical' method is responsible for initializing 
this state and this is easily accomplished by calling the superclass' 
canonical initializer.


Pattern 2:  Convenience Method

Problem:  Commonly repeated sequences of code increase the chance of 
error and obscure more important aspects.

Solution:  Define a method that aggregates the repeated sequence into a 
single message send.  For example, if a canonical initializer is 
frequently called with the same value for many of its arguments, 
replace these calls with a call to a convenience method that 
encapsulates these invariant values.  The invocation of the convenience 
method is syntactically shorter because it takes only the arguments 
that vary.


Pattern 3:  Default Constructor

Problem:  Users frequently need to obtain new objects with well defined 
state, but cannot be expected to understand how to reliably initialize 
that state.

Solution:  Require every class to have a method named 'defaultNew' that 
takes no arguments, but that creates a basic new instance and calls the 
canonical initializer for the object with default arguments.


It would seem to be a good idea to agree on  a "canonical initializer" 
prefix and "default constructor" name for squeak.  It is tempting to 
view "initialize" as the former and "new" as the latter, but this 
choice would imply that we need to correct lots of code.  Recent 
discussion suggests that there is too much opposition to redefining 
these common method names.  Choosing new names means that we have to 
write a lot of new and duplicated code wherever we want to take 
advantage of these patterns.

Richard Staehli



More information about the Squeak-dev mailing list