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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Mark Volkmann
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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
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 mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by K. K. Subramaniam
The initialize method on the class side will be called only when *the class* is initialised. You are thinking of the instance-side initialize method which is called each time you create an instance.
On 9/29/08, Mark Volkmann <[hidden email]> wrote:
On Sep 28, 2008, at 11:32 PM, K. K. Subramaniam wrote: _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On Sep 29, 2008, at 6:00 AM, Marcin Tustin wrote: The initialize method on the class side will be called only when *the class* is initialised. You are thinking of the instance-side initialize method which is called each time you create an instance. Wow. I wasn't aware that there was both a class and instance initialize method. Thanks for explaining that! What causes the class initialize method to be invoked ... and reinvoked after I change it?
--- Mark Volkmann _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On Mon, Sep 29, 2008 at 7:57 AM, Mark Volkmann <[hidden email]> wrote:
You have to explicitly call MyClass>>initialize after you change it. If you create a Monticello package, it also gets invoked after first loading the class... Rob _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Marcin Tustin
A class is "just" another object whose own class is Class. I actually don't know when the class initialisiation method is called after creation. As usual, if all it does is things you know to be safe, go ahead and call it manually.
On 9/29/08, Mark Volkmann <[hidden email]> wrote:
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On Mon, 2008-09-29 at 13:16 +0100, Marcin Tustin wrote:
> A class is "just" another object whose own class is Class. I actually > don't know when the class initialisiation method is called after > creation. As usual, if all it does is things you know to be safe, go > ahead and call it manually. > It is not called _after_ creation. You said it is just another object. And therefor it is part of the new call. The difference here is that when you create a class there is no initialize method. You define that later. So it is e.g. executed when load from Monticello or anything that creates the class at a whole including the initialize method. I hope that comes near to what happens really :) Norbert > On 9/29/08, Mark Volkmann <[hidden email]> wrote: > On Sep 29, 2008, at 6:00 AM, Marcin Tustin wrote: > > > The initialize method on the class side will be called only > > when *the class* is initialised. You are thinking of the > > instance-side initialize method which is called each time > > you create an instance. > > > Wow. I wasn't aware that there was both a class and instance > initialize method. Thanks for explaining that! > > > What causes the class initialize method to be invoked ... and > reinvoked after I change it? > > > On 9/29/08, Mark Volkmann <[hidden email]> wrote: > > 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 mailing list > > [hidden email] > > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > > > > _______________________________________________ > > Beginners mailing list > > [hidden email] > > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > --- > Mark Volkmann > > > > > > > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
>>>>> "Norbert" == Norbert Hartl <[hidden email]> writes:
Norbert> It is not called _after_ creation. You said it is just another Norbert> object. And therefor it is part of the new call. The difference Norbert> here is that when you create a class there is no initialize Norbert> method. You define that later. So it is e.g. executed when load Norbert> from Monticello or anything that creates the class at a whole Norbert> including the initialize method. Norbert> I hope that comes near to what happens really :) This dates back to the old .st fileins... the very last line of these fileins is "SomeClass initialize", meaning that the initialize method is actually called very explicitly once the class is loaded. Modern code management systems simulate this in various ways. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Free forum by Nabble | Edit this page |