Hi-
I generally just lurk around these parts.  I understood (as an old but 
still veritable newby) that using basicNew would bypass a modified new 
method in the superclass.  However, doing this would seem to fly in the 
face of subclassing in the first place, and may result from places where 
subclassing is not a good fit for the problem.  I would surmise (off the 
top of my head) that this is where Protocalls or Traits would prove 
their usefulness.  (how's this for superficial rationalization of a 
half-know subject?)
David


Anthony Adachi wrote:

>Yoshiki wrote: 
>
>  
>
>> > I see. So, there might not be any reason of
>>    
>>
>particular
>  
>
>> > significance why an author may have chosen one
>>    
>>
>over
>  
>
>> > the other?
>> 
>> One of the *reason*, which is merely a hypothetical
>>    
>>
>explanation, why
>  
>
>> we see many "super new initialize" would be that
>>    
>>
>those Smalltalkers
>  
>
>> steal code. They really do. The ones written early
>>    
>>
>days must be
>  
>
>> written in that way, and later people just copied
>>    
>>
>the old examples.
>
>  
>
>> Also, again, using methods whose name begins with
>>    
>>
>'basic' has some
>  
>
>> dangerous smell.
>>    
>>
>
>Not sure what you mean by that? Also, are you
>referring to redefining 'basicNew' or simply sending a
>message to 'basicNew'? Please explain.
>
>  
>
>> # Not to mention the fact that most of them are so
>>    
>>
>loosy that they
>  
>
>> # can't care such detail.
>> 
>> I'm now curious that why you want to know this
>>    
>>
>*reason* so badly:-)
>
>Well, I was simply looking for a good answer to
>this...
>
>Looking through the Squeak system I've seen both super
>new and self basicNew. Moreover, in a number of books
>& articles I've read, which were either on Smalltalk
>or which had Smalltalk code examples, I've noticed
>both implementations used.
>
>I was wondering why, if both effectively result in a
>new instance of the message receiver, then why did the
>people who wrote those methods chose one
>implementation over the other? Is there a good reason
>for making one choice over the other or not? Or is it
>just a matter of personal preference?
>
>The book, "Smalltalk Best Practice Patterns" by Kent
>Beck's, does cite a similar reason as Derek Brans had
>indicated... 
>
> "Use basicNew to create the instance to avoid
>accidently setting "initialize" off twice, should a
>future superclass invoke it. " e.g.-self basicNew
>initialize
>
>However, I had come across no explanations offering a
>good reason for using self new instead despite it's
>use in other examples.
>
>The initial reason for my desire to find this out was
>(and still have not finished) reading the "Squeak: A
>quick trip to ObjectLand" book and for some of the
>classes, required by the exercises, I created instance
>creation methods which ensured their instance
>variable(s) were initialized. Reason being, these
>variables were needed before the instances could be
>used. Since, the book up to that point hadn't
>explained how to do such a thing I perused the image
>for answers.
>
>Besides, I just simply wanted to know what was the
>most prudent way to implement a method which overrides
>new for future reference.
>
>By the way...
>
>  
>
>> I'm now curious that why you want to know this
>>    
>>
>*reason* so badly:-)
>
>I'm curious, as to why you asked such a question?
>
>Thanks,
>
>Anthony 
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
>
>
>  
>