Re: Overriding methods

Hi Blake,

You should *never* *never* *never* override #basicNew!  If fact, never  
override any #basic* methods.

If you override them, then you can't get at them anymore.  At some  
point you must actually create a new object, and the only way you can  
do this (well, the only reasonable way) is to eventually send  
#basicNew.  Of course #new does this for you, so if you override #new,  
or provide another way of creating instances, then that's where you  
will send #basicNew.

Maybe if you describe your problem, it would be easier to suggest a  
reasonable way of doing it.

- on

On Jan 20, 2008, at 10:45, Blake wrote:

> Hey, all:
>
>         I figure this is a beginner question.
>
>         I get a big warning when I override certain methods. (Class methods?)
>
> 	For example, if I want to set up the "contractless" part of my  
> object, I do so by overriding #basicNew, and then setting the values  
> that allow the instance of the object to function. This seems  
> perfectly normal and reasonable, but I get this big warning about  
> how terrible it might be.
>
> 	I not even 100% clear on how it could be so terrible beyond that  
> particular class. (I guess it's possible in this way to create an  
> object that destabilizes the system?)
>
> 	Am I doing this wrong/non-optimally? (Maybe I should be overriding  
> #new instead of #basicNew, but I get the same dire warning for #new).
>
>         ===Blake===
>
> P.S. Seeing if this goes through; last message I sent warned me that  
> I wasn't on the mailing list.
> _______________________________________________
> Beginners mailing list
> Beginners@xxxxxxxxxxxxxxxxxxxxxxxxxx
> http://lists.squeakfoundation.org/mailman/listinfo/beginners