Proposal: Squeak-E = Squeak x Kernel-E

Mark S. Miller markm at caplet.com
Fri Jan 31 06:21:17 UTC 2003


[quoting and answering out of order]

At 02:03 PM 1/26/2003 Sunday, Lex Spoon wrote:
>Without some kind of  global variables, you don't have Smalltalk.  Consider
>the globals "Array" and "World", for example.  How do you get access
>to these things?  Fundamentally, your code is just going to say "I want
>an Array class" or "I want access to the current graphical world".
>No matter how much syntax you clutter it with, this is conceptually
>a global variable.

Your example is perfect: From my point of view, World and Array couldn't be 
more different. I am not against a global scope, so long as this scope is 
transitively read-only (transitively immutable is preferred but not 
required), and contains no objects conveying any authority -- where 
"authority" is loosely defined as the ability to affect or be affected by 
the world outside of oneself.

Array should not be a problem. Because Squeak evolved without capability 
discipline in mind, there may very well be methods on Array that cause a 
problem -- I haven't looked -- but I'm confident that any such problems are 
incidental and could be tamed or refactored away. The remaining mutability 
reachable from Array is the mutability of Smalltalk Classes, which your 
paper already shows how to address. Let's assume for the moment that this 
has been successfully addressed.

The global scope itself must also be read-only. Therefore, the global 
variables in that scope can be read but not assigned into.

The object globally known as "Array" would then be transitively immutable 
and convey no authority. It can be used to create mutable objects, which is 
fine. Two mutable objects separately created by Array in response to two 
separate requests cannot share any mutable state, even if the author of 
Array wishes them to do so. If Array is installed according to these rules, 
no human being need inspect the code to be sure this property holds -- the 
property is enforced by implication from the rules. The result is that two 
objects which share access to Array cannot use this shared access to 
communicate with each other, even if they are collaborating with the author 
of Array.

More later...


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM



More information about the Squeak-dev mailing list