Thanks avi for this post.

  This is always worth been reminded that we are not the center of  
universe :)


On Vendredi, sep 12, 2003, at 04:55 Europe/Zurich, Avi Bryant wrote:

> On Thursday, September 11, 2003, at 05:57  PM, Julian Fitzell wrote:
>
>> If I remove the call to "super initialize" from #initializeWithClass:  
>> then it still doesn't work because then #initialize (and therefore  
>> #beExclusive) is called before I've added my sub filters.  The only  
>> way to make it work as I desire is to use #basicNew in my #forClass:  
>> method, which I'm led to believe is not considered the right way to  
>> do such things.
>
> 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
>
> I'll try to summarize, translated into Smalltalk terms:
>
> - Object provides a blank #initialize method.  This, like all  
> initialization methods, may be overriden.
>
> - Every class has exactly one "designated initializer" method.  If a  
> class has more than one initialization methods, the designated  
> initializer is the most general or the most canonical - usually the  
> one with the most arguments.  For example, for a Point the designated  
> initializer might be this:
>
> initializeWithX: xNumber y: yNumber
>   super initialize.
>   x := xNumber.
>   y := yNumber.
>

This practice is not really good.

should not it be:
> initializeWithX: xNumber y: yNumber
>   self initialize.
>   x := xNumber.
>   y := yNumber.


> - The designated initializer must call its superclass' designated  
> initializer.  Here, because Point is a subclass of Object, and  
> #initialize is the designated initializer for Object,  
> Point>>initializeWithX:y: must call Object>>initialize.
>
> - All other initializers must call the designated initializer.  For  
> example, you might (for some reason) have an initializer that just  
> took an X value:
>
> initializeWithX: aNumber
>   self initializeWithX: aNumber y: 0.
>
> They do *not* call any super methods.
>
> - The above rule also applies to any inherited designated  
> initialization methods - they have to be rewritten in terms of the new  
> designated initializer.  So, you would have to add an #initialize  
> method:
>
> initialize
>   self initializeWithX: 0 y: 0

Would loop with y change
>
> - Any initializer, designated or not, may have a corresponding class  
> side method.  For example, Object provides Object class>>new which  
> corresponds to #initialize.
>
> new
>   ^ self basicNew initialize
>
> These class side methods always call #basicNew and their intialization  
> method.  They do not get overriden.  Point might provide:
>
> x: xNumber y: yNumber
>   ^ self basicNew initializeWithX: xNumber y: yNumber
>
> x: aNumber
>   ^ self basicNew initializeWithX: aNumber

> Note that the inherited #new will call the overridden  
> Point>>initialize, which will provide the default 0 at 0 values, so  
> there's no way to get an inconsistent instance (without directly using  
> #basicNew).
>
> So, the short answer to Julian's question is: yes, use #basicNew in  
> #forClass:.  If you make sure to follow the rest of these conventions,  
> the problems that people have with #basicNew (in terms of missing  
> superclass initialization) should not come up.

Yes you push everything to the instance side which is good. Still you  
do not solve the problem to have to understand
a lot before having a simple object well initialized.

I do not remember: do class methods in object-c static (not method  
lookup = more constructor like in Java) or real methods?

Stef