On Wed, 04 Jul 2007 10:09:30 +0200, sig <siguctua at gmail.com> wrote:

> 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).

Indeed, they are. Inspect (Smalltalk specialObjectsArray). And since it's  
Smalltalk, you can pass your own (0 class) and (nil class) to the VM :)

BTW nil,false,true are associated with their respective bytecode. So  
compiler knows that VM knows how to access objects in (Smalltalk  
specialObjectsArray).

/Klaus

> 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)]
>>
>>
>>
>
>