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
|