Initializing class variables

Hi,

This miht be a silly question, but where am I suposed to initialize
class variables? O:-)

TIA

Fernando schrieb:
> Hi,
>
> This miht be a silly question, but where am I suposed to initialize
> class variables? O:-)
>
> TIA
>
Fernando,

you can do that "Lazy style" ie.

YourClass class VariableName

VariableName isNil ifTrue:[VariableName := initialValue].
^VariableName


Günther

Fernando,

> This miht be a silly question, but where am I suposed to initialize
> class variables? O:-)

You can do it in a class-side #initialize.  Please do _not_ super-send
in these methods, or at least recall that you have been warned ;)  The
problem is that you might re-initialize events for critical system
objects and and up with a development environment with a significantly
reduced work ethic.

AFAIK, the class #initialize method is evaluated on package loading and
.st/.cls file-in.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

>AFAIK, the class #initialize method is >evaluated on package loading
and
>.st/.cls file-in.

And who sends the #initialize message?
Am I suposed to do that for my classes?

Fernando wrote:

> And who sends the #initialize message?

The system sends #initiallizeAfterLoad to the class as packages are loaded.
That then checks to see if your class has an explicit implementation of
#initialize, and if it does then it calls it.

So you don't have to call it yourself.  However if you are developing a new
class, the system doesn't know to invoke its #initialize method (and it would
probably cause chaos if it did, since it would call it while you were still
writing the class).  So you'll see a lot of class-side initialisation methods
have comments something like:

    initialize
        "blah blah....
                self initialize.
        "
        ... real code ...

so that it's easy to select the "self initialize" in the comment and execute
it.

The system similarly sends #uninitialize to classes just before they are
unloaded as a package is removed.

There's also a similar method that's sent just before image stripping starts,
but I can't remember what that's called...

    -- chris

Fernando,

>> AFAIK, the class #initialize method is
>> evaluated on package loading
>> and st/.cls file-in.
>
> And who sends the #initialize message?
> Am I suposed to do that for my classes?

Just to tidy up a bit.  I don't think that .st/.cls file-ins invoke any
initialization at all.  If you need to do it automatically then you will
have to manually edit the file to add an extra chunk at the end.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi Fernando,

since I myself am also learning Smalltalk I am also interested in
initialization matters.

So far I found out several possibilities for the instance side, by
overriding the method new:
    new
    ^super new initialize
or
    new
    ^self basicNew initialize
where initialize is an instance method. Choosing between the two depends on
whether new already has been overridden by one of the superclasses.

I also found out that some Smalltalks have a built-in calling mechanism to
call the instance method initialize.

As Bill told, a class side initialize method is also possible. However, that
leaves me with the question:
    what to do when you need an initialize method for both the class AND the
instance side????

Studying this phenomenon I found this very interesting article:
    http://www.smalltalksystems.com/publications/class_initialize.doc

Met vriendelijke groet / with kind regards,
   Arie van Wingerden

"The best way to predict the future is to invent it."
  # Alan Kay #


"Fernando" <[hidden email]> schreef in bericht
news:[hidden email]...
> Hi,
>
> This miht be a silly question, but where am I suposed to initialize
> class variables? O:-)
>
> TIA
>

Arie van Wingerden wrote:

> As Bill told, a class side initialize method is also possible. However,
> that leaves me with the question:
>     what to do when you need an initialize method for both the class AND
> the instance side????

Just have #initialize methods on both the instance-side and the class-side.
Since the instances and the class are different objects the "right" #initialize
will be sent to the right objects.

    -- chris

oops, that is of course how it works! Just that simple!

Thx,
   Arie van Wingerden

"The best way to predict the future is to invent it."
  # Alan Kay #


"Chris Uppal" <[hidden email]> schreef in bericht
news:4213e320$1$38046$[hidden email]...
> Arie van Wingerden wrote:
>
> > As Bill told, a class side initialize method is also possible. However,
> > that leaves me with the question:
> >     what to do when you need an initialize method for both the class AND
> > the instance side????
>
> Just have #initialize methods on both the instance-side and the
class-side.
> Since the instances and the class are different objects the "right"
#initialize
> will be sent to the right objects.
>
>     -- chris
>
>

Arie van Wingerden wrote:
> oops, that is of course how it works! Just that simple!

Perhaps I'm stating the obvious, just a few more comments (based on my
own learning-curve):

- The class-side initialize method MUST have the name #initialize and -
as Bill already mentioned, you MUST NOT call "super initialize" in that
method.

- The instance-side initialize-method can have any name and generally
you WILL super-send in that method (assuming the superclass has an
initilize method as well). The fact that it can have any name is useful
to initialize the receiver, i.e. assume the class hierarchy:

Object
   Superclass
     Subclass (with instance variables: var1 var2)

with the methods:
   Superclass class>>new
     ^super new initialize

   Superclass>>initialize
     [...]
     ^self

   Subclass class>newVar1: v1 var2: v2
     ^self basicNew initializeVar1: v1 var2: v2


   Subclass>>initializeVar1: v1 var2: v2
     super initialize.
     var1 := v1.
     var2 := v2.
     ^self


- Also note that in this example the coding of "Subclass class>>new"
contains "self basicNew" instead of "super new", otherwise the method
"Superclass>>initialize" would be invoked twice.

- Of course if the initialize method in the subclass would have also had
the name #initialize, then you wouldn't have needed the class methods in
Subclass at all.


Hope, that this helps to avoid some pitfalls I ran into at one time or
another, :)

Bernhard

>So you don't have to call it yourself.  However if you are developing
a new
>class, the system doesn't know to invoke its #initialize method (and
it would
>probably cause chaos if it did, since it would call it while you were
still
>writing the class).

And how can you instruct the system to start calling the #initialize on
start up?

Fernando,

> And how can you instruct the system to start calling the #initialize on
> start up?

Normally you wouldn't.  There are three different scenarios that you need to
look at.

1) Loading a package into the system.  Any class side #initialize is
automatically called as part of the load process - as Chris detailed.

2) During development/testing.  This is when you manually evaluate the code
in the methods comment.  If you edit the #initialize method then you need to
remember to, and have an easy way to, reinitialize the class' state.

For both of the above you must remember that if you subsequently save the
image the class will remain initialized, it's state will be retained, so it
is not necessary to #initialize it again.

3) Every time the image starts.  The best way is to register for an event
that the image triggers when it starts up.

SessionManager current when: #sessionStarted send: #onStartup to: self.

The standard naming convention would use a method named #onStartup which can
just call #initialize.  You only really need to use this if you have
something external to the Dolphin image that needs setting up or class state
that needs resetting (OS handles for example).  For most classes the
retention of the class state by the image save is enough.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Thanks Ian,  I got it now. :-)