hi richard


I like the patterns.
just a point I did not see too much opposition.


Stef


On Vendredi, sep 12, 2003, at 20:50 Europe/Zurich, Richard Staehli 
wrote:

> 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
>
>