SmalltalkImage current

> I don't think that's such a horrible or tragic outcome. Squeak  
> benefits greatly from Stephane's work (IMO), so it's a loss in one  
> sense if he decides not to work on it, but at the same time, if  
> he's frustrated by those who are at cross-purposes, a fork is a  
> good solution.
>
> On the one hand, Smalltalk is meant to be altered in dramatic ways,  
> on the other, people are trying to get work done. Those two  
> purposes are going to cross at times.
>
> ===Blake===
>
>

>
> Hi all--
>
>      I'd just like to remind everyone again of my design for shared
> variables from July of last year[1], implemented in Spoon at that time.
> I removed SystemDictionary; each class is responsible for its own name
> literal (so each one appears in only one place, instead of the two we
> had before). Each class name literal (an association between a symbol
> and a class object) is unique, so the name symbols need not be. Humans
> can distinguish classes from one another without regard to name by other
> means (e.g., author, version, class categories, object identity), with
> help from the development tools. Given this support, there is no need
> for namespaces in the common sense; the name symbol of each class can be
> anything, so in effect each and every class has its own namespace.
>
>      As for where to put the behavior formerly provided by the
> SystemDictionary instance, I prefer that it live at (Interpreter class).
> A normal system will have only that behavior there, a system with the
> support to actually build an interpreter will have a bunch more
> (currently provided by the VMMaker package).
>
>      Please see the design for more details.
>

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

>
> Hi all--
>
>      I'd just like to remind everyone again of my design for shared
> variables from July of last year[1], implemented in Spoon at that
> time. I removed SystemDictionary; each class is responsible for its
> own name literal (so each one appears in only one place, instead of
> the two we had before). Each class name literal (an association
> between a symbol and a class object) is unique, so the name symbols
> need not be. Humans can distinguish classes from one another without
> regard to name by other means (e.g., author, version, class
> categories, object identity), with help from the development tools.
> Given this support, there is no need for namespaces in the common
> sense; the name symbol of each class can be anything, so in effect
> each and every class has its own namespace.
>
>      As for where to put the behavior formerly provided by the
> SystemDictionary instance, I prefer that it live at (Interpreter
> class). A normal system will have only that behavior there, a system
> with the support to actually build an interpreter will have a bunch
> more (currently provided by the VMMaker package).
>
>      Please see the design for more details.
>

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

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

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

> 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 <[hidden email]> 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)]
>>
>>
>>
>
>

> On Wed, 04 Jul 2007 10:09:30 +0200, sig <[hidden email]> 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).
>