On Fri, Sep 26, 2003 at 09:10:42AM -0600, Brian Brown wrote:
> 
> On Friday, Sep 26, 2003, at 06:52 America/Denver, Matej Kosik wrote:
> 
> > On Fri, Sep 26, 2003 at 09:25:32AM +0200, Brent Pinkney wrote:
> >>>
> >>> anInstanceVar
> >>> anInstanceVar ifNil: [
> >>> anInstanceVar _ someInitializationCode.
> >>> ].
> >>> ^ anInstanceVar
> >>>
> >> This is more terse:
> >>
> >> anInstanceVar
> >>
> >> 	^ anInstanceVar ifNil: [ anInstanceVar := someInitializationCode ]
> >
> > Someone might prefer this approach. I have seen this approach regularly
> > used in the code generated by VisualWorks GUI builder and (to my
> > disappointment) also in some random places in Morphic classes.
> >
> 
> [snip]
> 
> > I do not like it. The trivial method which should do nothing more
> > but return the value of the appropriate instance variable is spoiled
> > by some superfluous stuff.
> >
> > I always initialize instance variables in "constructors".
> >
> > I didn't see that ifNil: practise anywhere within the Purple Book.
> > Fortunatelly the method Point>accessing>x does not look like this:
> >
> >   ^x ifNil: [x := 0]
> >
> > but thankfully like this
> >
> >   ^x
> >
> > I like it.
> >
> 
> Welcome Phil, and Hello Matej ;-)
> 
> I don't know about the Purple Book, but I find both the Lazy 
> Initialization and what your are talking about Matej, Common State in 
> the Smalltalk Best Practices Book (Kent Beck).

I see that lazy initialization might be useful (to make the code more
effective) in some occastions. For example when some owned object
are more likely not to be accessed than accessed (however I didn't read
the aforementioned book so may be there are other occassions where
it might be appropriate - I do not know).

(1?) The thing I do not understand particularly in case of StringMorph is
why the instance variables of the new object are not properly initialized
during the construction time. The instance variables are likely to
be accessed (font, emphasis).

(2?) I would prefer something like this (in case when we need not fear
of the nil in the instance variables)

#font method returns the `font' instance variable immediatelly
i.e. does something like

	^ font

#font: method sets up the `font' instance variable but preserves the emphasis

#emphasis would return the emphasis of the font

#emphasis: would set up the new emphasis but preserves the font (name/family or how it is called in the Squeak terminology).

The method #fontToUse should be thrown away.

1- there is a #fontToUse method which is very awful
2- if you change the emphasis, (with #emphasis:) method, the font will
   change to the default font, This is (in my opinion) a bug.
3- if you change the font, (with #font:) method, the emphasis is reset to 0
   (plain) ... (this behaviour however might be considered as a feature rather
   than bug if we agree on that)

I have played with this issue for certain time but then gave it up because
the code is not completely comprehensive to me. It is not trivial.

> 
> The principal difference is whether you know beforehand if a variable 
> is likely to be used and want to save space/resources if it won't. I 
> typically use Lazy Initialization for simple instance vars like strings 
> and numbers and even Collections, but use constructors and initialize 
> methods for more complex objects that I know will be used.
> 
> ;-)
> 

-- 
Matej Kosik <http://altair.dcs.elf.stuba.sk/wiki/Main/MatejKosik>
ICQ: 300133844