On Wed, 04 Jul 2007 10:09:30 +0200, sig siguctua@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@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 sendinga 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 provideaccess 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)]