Hi julian

you are right.
Automatic initialization does not solve everything. But this is the 
simplest change that provide the maximum.
Else you would like to have init value for attributes or declaration 
for declaring your objects.

Stef

On Vendredi, sep 12, 2003, at 02:57 Europe/Zurich, Julian Fitzell wrote:

> Richard A. O'Keefe wrote:
> [...]
>> There are far too many classes in Squeak which *have* a #new method
>> which can create an unusable object.  It seems most unwise to do 
>> anything
>> to encourage this.
>
> Since you can create *any* object with a #new method I would argue 
> that even *without* having #new call #initialize, most classes in 
> Squeak can create a an unusable object.
>
> But, you raise some interesting points and I have just in the past few 
> days come across a few cases in my code where having #new call 
> #initialize is problematic.  For example, I have a filter class that 
> contains something kind of like the very simplified code below:
>
> Filter>>initialize
>   self beExclusive.
>
> Filter>>beExclusive
>   default := #exclude.
>
> Filter (class)>>new
>  ^ super new initialize
>
> Then I have a subclass of Filter, CompositeFilter, which has:
>
> CompositeFilter>>initializeWithClass: aModelObjectClass
>   self addSubFiltersForAttributesOf: aModelObjectClass.
>   super initialize.
>
> CompositeFilter>>beExclusive
>   super beExclusive.
>   self subFilters do: [:each | each beExlusive]
>
> So now how do I create a CompositeFilter?  If I define a constructor 
> as follows:
>
> CompositeFilter (class)>>forClass: aModelObjectClass
>   ^ self new initializeWithClass: aModelObjectClass
>
> then #initialize gets called twice.  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.
>
> It seems like initialization always need to start from the subclass 
> level.  So if I have a more specific initialization method, it should 
> be able to determine at what point to call the superclass 
> initialization method (and in fact even *which* superclass 
> initialization method to call in the first place).  This becomes 
> impossible when it is passed in an object that has already been 
> partially initialized by a call to #new.
>
> Anyway, not sure exactly what the solution is, but I thought I'd throw 
> in these recent observations for discussion.  I'm trying to remember 
> the code off the top of my head from home, so if there are obvious 
> errors, that's why :)
>
> Julian
>
>
> -- 
> julian at beta4.com
> Beta4 Productions (http://www.beta4.com)
>
>