Roel Wuyts <wuyts at iam.unibe.ch> wrote on 16.09.2003 11:08:05:
>
>On Monday, Sep 15, 2003, at 12:34 Europe/Zurich, Martin Wirblat wrote:
>
>>> Sorry, but its part of the Smalltalk conventions to make new send
>>> initialize (see the Kent Beck book about Smalltalk best practice
>>> patterns).
>>
>>
>> Nouri,
>> would you agree that the _general_ Smalltalk convention in reality
>> ( implementations, ANSI ) is that #new is not sending #initialize?
>
>Again, this grew historically.... and historic choices or usefulness, 
>however necessary and thought-over in their time, can turn out to be 
>no longer valid currently. Hence we can change them. I refuse to let 
>the library come to a standstill for *historic* reasons!
>
No need to refuse such thing: the only possible implication of Noury's 
idea that Kent is part of Smalltalk convention with regard to the 
context of my message is, that everyone knows that #new sends 
#initialize, and that is wrong, and that's all I wanted to express.  
------
------
Roel Wuyts <wuyts at iam.unibe.ch> wrote on 16.09.2003 11:04:14:
..
>> It is even more error prone if #new is calling #initialize by 
>> default. It is by far more likely that one forgets OR does not know 
>> at all that #new 'silently' and against all Smalltalk conventions 
>> sends #initialize, than that one forgets to have a look at the super
>> implementation if he calls it.
>
>That is general Smalltalk practice to have a look at yoour 
>superclasses to see whether one of your superclasses already 
>implement it... This is the same for such an initialize method. One 
>can also forget to look at #postCopy, or forget a 'super postCopy', 
>or directly override #copy for adding copying behaviour (been there, 
>done that). 
>
#initialize is sent by a super method with a _different_ selector! 
That is different to override #new and have a look in the superclasses 
for the same selector. And that is part of why I think that the status 
quo is less error prone than Noury's idea. 
------
------ 
>> There will be made many mistakes by those who are not accustomed to
>> this behavior.
>
>As is with most changes. So should Squeak come to a standstill for 
>the sake of backwards compatibility?
>
Again, you are ripping out of and placing into another context what I 
said. I am just evaluating what Noury called a plus - less error prone 
- and get to the conclusion that the opposite probably is true. 
------ 
------ 
>> Additionally I think it is really easy to forget about it: If one
>> plans to use #initialize for resetting or preparing later on etc,
>> rather than for creating, it may not come to ones mind that during
>> creation it is called too.
>
>Calling such a 'reset' method 'initialize' is not good... it is a 
>hack, and that is what you pay for it. At least, one should implement 
>a method #reset that just calls 'self initialize' - that way it is 
>clear that in that case the reset is just an initialize.
>
The problem here is that the by many programmers associated semantics 
of #initialize is broader than what would be good for your idea. You 
can see this if you look where #initialize is sent not during creation 
time ( what you think should be called #reset etc ). I think this 
shows clearly that there are programmers who think #initialize is not 
only for creation of an object. And this will lead to mistakes. To say 
no one should call 'reset' 'initialize' is only saying no one should 
make mistakes.

Regards,
Martin