How are constants represented in Smalltalk? Do you create a method whose name is the name of the constant and return the value?
--- Mark Volkmann
On Sun, 2008-09-28 at 07:54 -0500, Mark Volkmann wrote:
How are constants represented in Smalltalk? Do you create a method whose name is the name of the constant and return the value?
You have several ways to define something you could call "constant". If we see a constant as a global accessible thing that doesn't change and has something like a name you have multiple options:
- #myConstant Symbol. That is globally available and is always the same object.
- a class. A class is an object with a name that is globally accessible and gives the same object everytime
- cached instances. You define class methods that create instances and cache the instances. This way you get the same object everytime you invoke the class method
I think there even more possibilities. What you should use depends on what you are trying to achieve. A symbol is just the name. A class serves this purpose quite well for a lot scenarios. But you don't want to create classes only because you need some constant value.
Norbert
On Sep 28, 2008, at 8:33 AM, Norbert Hartl wrote:
On Sun, 2008-09-28 at 07:54 -0500, Mark Volkmann wrote:
How are constants represented in Smalltalk? Do you create a method whose name is the name of the constant and return the value?
You have several ways to define something you could call "constant". If we see a constant as a global accessible thing that doesn't change and has something like a name you have multiple options:
- #myConstant Symbol. That is globally available and is always
the same object.
- a class. A class is an object with a name that is globally
accessible and gives the same object everytime
- cached instances. You define class methods that create
instances and cache the instances. This way you get the same object everytime you invoke the class method
I think there even more possibilities. What you should use depends on what you are trying to achieve. A symbol is just the name. A class serves this purpose quite well for a lot scenarios. But you don't want to create classes only because you need some constant value.
I think my main issue is scoping. I want to define a constant that is associated with a class to avoid name conflicts. Maybe that's not the Smalltalk way. Similarly I'm concerned about defining a class, then later installing a library that contains a class with the same name as one of mine. Does that issue come up very often? I'm concerned about the lack of support for namespaces (packages in Java).
--- Mark Volkmann
On Sun, 2008-09-28 at 08:56 -0500, Mark Volkmann wrote:
On Sep 28, 2008, at 8:33 AM, Norbert Hartl wrote:
On Sun, 2008-09-28 at 07:54 -0500, Mark Volkmann wrote:
How are constants represented in Smalltalk? Do you create a method whose name is the name of the constant and return the value?
You have several ways to define something you could call "constant". If we see a constant as a global accessible thing that doesn't change and has something like a name you have multiple options:
- #myConstant Symbol. That is globally available and is always
the same object.
- a class. A class is an object with a name that is globally
accessible and gives the same object everytime
- cached instances. You define class methods that create
instances and cache the instances. This way you get the same object everytime you invoke the class method
I think there even more possibilities. What you should use depends on what you are trying to achieve. A symbol is just the name. A class serves this purpose quite well for a lot scenarios. But you don't want to create classes only because you need some constant value.
I think my main issue is scoping. I want to define a constant that is associated with a class to avoid name conflicts. Maybe that's not the Smalltalk way. Similarly I'm concerned about defining a class, then later installing a library that contains a class with the same name as one of mine. Does that issue come up very often? I'm concerned about the lack of support for namespaces (packages in Java).
You can have a look at the archives of the squeak-dev mailing list. Namespaces is one of the topics that appear regularly on the list :) The discussions about it are quite good and give you good insights in this topic. And you'll might see the need to take off the java glasses if you deal with Smalltalk ;)
Norbert
On Sunday 28 Sep 2008 7:26:43 pm Mark Volkmann wrote:
I think my main issue is scoping. I want to define a constant that is associated with a class to avoid name conflicts.
See classes Color, Cursor or Float for examples of scoped constants: Color red Cursor wait Float pi
For constants that should be exposed to a few (but not all) classes, use pool dictionaries.
HTH .. Subbu
On Sep 28, 2008, at 11:32 PM, K. K. Subramaniam wrote:
On Sunday 28 Sep 2008 7:26:43 pm Mark Volkmann wrote:
I think my main issue is scoping. I want to define a constant that is associated with a class to avoid name conflicts.
See classes Color, Cursor or Float for examples of scoped constants: Color red Cursor wait Float pi
For constants that should be exposed to a few (but not all) classes, use pool dictionaries.
Thanks! This brings up another question. Where is a good place to initialize a constant? I see in the case of "Float pi" that it is held in a class variable that is initialized in the initialize method. Isn't it the case that the initialize method is only called if a Float object is created? Also, isn't it called every time a Float object is created? It seems that would mean if I followed that pattern for one of my own constants then I wouldn't be sure it was set and I'd pay the cost of setting it many times.
--- Mark Volkmann
beginners@lists.squeakfoundation.org