SmalltalkImage current

sig siguctua at gmail.com
Wed Jul 4 08:09:30 UTC 2007


I like it. Now the final question on road to remove globals at all :
what you propose to do with these three symbols:
#nil
#true
#false
?
And, maybe this is not related problem - what strategy for accessing
class of smallint objects, because there's no direct information in
smallint object about its class, because its tagged oop, not mem oop
in squeak. I know this is mostly a VM responsibility, but still it
introduces a limitations: VM must know a sole instance of SmallInteger
class and thus it must be global in VM's context (can't say if it
global in language context).
And also, if nil object represented by machine word, with all bits =
0, its too , can't point to own class directly.

I assume, these associations must be held somewhere in Interpreter
class, because its a reflection of VM (or smalltalk environment).

On 04/07/07, Craig Latta <craig at netjam.org> wrote:
>
> 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