Re: Overriding methods

Hi Blake!

I've yet to find a situation where I can't put the code that would be in a
constructor in C++ into #initialize.  I suppose there are situations where
that would be a bad idea, but I just haven't met them, or else I'm doing
bad things (very likely).

Every time I get that kind of a warning I treat it as a 'is there a better
way?' flag.  It'd be great if one of the non-newbies on this list could
explain when (or why) it is a better idea to override #new rather than
instantiate fields in #initialize or via lazy initialization.

yours in confusion,

John.


> 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
>