SmalltalkImage current

Craig Latta craig at netjam.org
Tue Jul 3 22:12:10 UTC 2007


Hi--

> what to do with global variables, which is identified by name?

     From the Spoon mailing list message I just mentioned[1]:

***

     I addressed the associations [in the SystemDictionary instance]
that refer to classes, but there are others. These are the other
so-called "global" variables (like Display, the primary display) as well
as all the "shared pools" (like TextConstants and, strictly speaking,
Undeclared). I think each currently-global variable should be the
responsibility of some class. So the primary display could be something
you get by sending "primary" to DisplayScreen.

     Shared pools are dictionaries of shared-variable associations,
similar to the system dictionary (in fact, I'd call the system
dictionary just another shared pool). I know some think we should simply
banish all shared pools, but I'll assume for the moment that we're
keeping them. I find them useful, I just think some class should take
responsibility for each one. I've added a "publishedPools" instance
variable to Class, which stores all the shared pool dictionaries for
which a class has responsibility (i.e., the class that introduced the
pool into the system). I renamed the traditional "sharedPools" instance
variable in Class to "receivedPools"; these are the pools that a class
merely uses. Finally, I renamed the "classPool" instance variable to
"classVariablesPool", just to be clearer.

     When you want to use a shared pool, you access the pool by sending
a message to the responsible class, rather than relying on its name
being a "global variable".

***

     And to that I'll just add that each responsible class can provide
access to individual published variables by direct message when appropriate.


     thanks again,

-C

[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]




More information about the Squeak-dev mailing list