[vwnc] Question about Class Methods and Variables

I have a few newbie questions regarding class variables and class
methods in Smalltalk:

1. Is there any way to guarantee that the Class >> initialize message
will be sent to set the values of uninitialized class variables? For
example, the Date class has several Arrays holding month names and
similar such info. If I hand out my own version of Date, how do I
guarantee that my Date class is properly initialized before end users
try to instantiate Dates?

2. In Smalltalk, are there rules of thumb for when you hoist a method
into the class? Obviously, when the method is used for class creation,
but when else? Again, there are several utility methods in Date on the
class side. Is this normal? In Java, I usually make that move when the
method is closely coupled to the class but doesn't use instance
variables.

Thanks,

David
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

For #1, there are pre and post loaded methods which are called automatically in the package when those events occur.
You can implement initialization methods for classes there, this guarantees that the classes are prepared for use...

regards,

David

On Sun, 2009-03-22 at 23:26 -0700, David Finlayson wrote:

I have a few newbie questions regarding class variables and class
methods in Smalltalk:

1. Is there any way to guarantee that the Class >> initialize message
will be sent to set the values of uninitialized class variables? For
example, the Date class has several Arrays holding month names and
similar such info. If I hand out my own version of Date, how do I
guarantee that my Date class is properly initialized before end users
try to instantiate Dates?

2. In Smalltalk, are there rules of thumb for when you hoist a method
into the class? Obviously, when the method is used for class creation,
but when else? Again, there are several utility methods in Date on the
class side. Is this normal? In Java, I usually make that move when the
method is closely coupled to the class but doesn't use instance
variables.

Thanks,

David
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group Phone 613 722 2091 extension 5 http://www.sageteagroup.com There are 10 different kinds of people in the world, those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

David Finlayson wrote:
1a) When a class is loaded the first time (from parcel or package) the
loader will call #initialize if the class implements this - I imagine
the same holds for Shared variables.
Note that this only is done the first time a class is loaded, if you
load a newer version of a package over an already existing version in
your image these methods will *not* be called, so simply implementing
initializers should be enough for basic deployment purposes.

1b) In the package properties you can declare a 'post load block', a
snippet of code to run after the package has loaded. This block is
called on every load -- regardless of whether an older version was in
the image before the load.

> 2. In Smalltalk, are there rules of thumb for when you hoist a method
> into the class? Obviously, when the method is used for class creation,
> but when else?
Utility methods that belong to no class in particular. (see SytemUtils)
Globally available constants (Filename class>>imageExtension) and
variables (WindowManager class>>managerRegistry)
Globally applicable operations (Windowmanager
class>>beEffectivelyModeless, ObjectMemory class>>quit)
Utilities that query global state (DebuggerService
class>>activeWindowManager)
Declaring default collaborator types that can be overridden in
subclasses (implementors of #compilerClass)
To implement singleton pattern (or other registries -- closely tied to
instance creation, see references to HandleRegistry).
Maintaining resources (implementers of #windowSpec) and documentation
(senders of #comentOnly)
Devlopment utilities/sledgehammers

And the kicker: when you need to override the behavior of Behavior
(see #compilerClass again and #extraAttributesForDefinition)


I'm sure there are gazillions of other uses, trawl your image for
examples ;-)

R
-


--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

David Finlayson wrote:
1a) When a class is loaded the first time (from parcel or package) the
loader will call #initialize if the class implements this - I imagine
the same holds for Shared variables.
Note that this only is done the first time a class is loaded, if you
load a newer version of a package over an already existing version in
your image these methods will *not* be called, so simply implementing
initializers should be enough for basic deployment purposes.

1b) In the package properties you can declare a 'post load block', a
snippet of code to run after the package has loaded. This block is
called on every load -- regardless of whether an older version was in
the image before the load.

> 2. In Smalltalk, are there rules of thumb for when you hoist a method
> into the class? Obviously, when the method is used for class creation,
> but when else?
Utility methods that belong to no class in particular. (see SytemUtils)
Globally available constants (Filename class>>imageExtension) and
variables (WindowManager class>>managerRegistry)
Globally applicable operations (Windowmanager
class>>beEffectivelyModeless, ObjectMemory class>>quit)
Utilities that query global state (DebuggerService
class>>activeWindowManager)
Declaring default collaborator types that can be overridden in
subclasses (implementors of #compilerClass)
To implement singleton pattern (or other registries -- closely tied to
instance creation, see references to HandleRegistry).
Maintaining resources (implementers of #windowSpec) and documentation
(senders of #comentOnly)
Devlopment utilities/sledgehammers (DefineOpcodePool class)

And the kicker: when you need to override the behavior of Behavior
(see #compilerClass again and #extraAttributesForDefinition)


I'm sure there are gazillions of other uses, trawl your image for
examples ;-)

R
-


--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Mar 23, 2009, at 1:57 AM, Reinout Heeck wrote:

> Utility methods that belong to no class in particular.

With the caveat that sometimes, you're still looking for the object  
you really should be creating as opposed to building "bags of  
functions." See SystemUtils :)

--
Travis Griggs
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre  
Leval




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Regarding #1:

To ensure that class shared and instance variables are initialized
properly, I tend to write a class-size accessor that lazily
initializes it, and then only refer to the variable through that
method.  For example:

Foo class>>someClassVar
   " self someClassVar "
   ^SomeClassVar ifNil: [SomeClassVar := 42]

Then I'll either write the corresponding setter method or a "reset"
method that sets it back to nil, and possibly do the reset from the
class-side #initialize method as well.

- Ash

On Mon, Mar 23, 2009 at 2:26 AM, David Finlayson <[hidden email]> wrote:
...
>
>
> Thanks,
>
> David
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



--
http://twitter.com/smashwilson

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Mar 22, 2009, at 11:26 PM, David Finlayson wrote:

> 2. In Smalltalk, are there rules of thumb for when you hoist a method
> into the class? Obviously, when the method is used for class creation,
> but when else? Again, there are several utility methods in Date on the
> class side. Is this normal? In Java, I usually make that move when the
> method is closely coupled to the class but doesn't use instance
> variables.

I like to anthropomorphize in my mental model of Smalltalk, a lot. The  
real-world metaphor that I often find myself relying on, when it comes  
to the subject of which behavior, should correctly be attributed to  
the class, is the idea of "factories." Given an object like "Point"  
the Point class is where I go to see how these things are made. It's  
like going on tour of a local manufacturing facility. And I find  
myself asking, "if I were a consumer of Points, and I were to go to  
the Point factory, what types of behavior might I expect to see there  
at the factory?" Maybe some jigs for common Points (zero and unity).  
The main lines where most of the point orders are filled (x:y: and the  
loss leader r:theta:). And a service department  
(decodeFromLiteralArray:) and finally the marketting group  
(toolListIcon).

Don't know if this helps at all. I often play this game when  
contemplating whether a given behavior really is the purvey of the  
class of a given object.

--
Travis Griggs
Objologist
One man's blue plane is another man's pink plane.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc