Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)

Lex Spoon lex at cc.gatech.edu
Thu Jan 30 09:21:03 UTC 2003

Avi Bryant <avi at beta4.com> wrote:
> On Wed, 29 Jan 2003, Lex Spoon wrote:
> > Either way should be fine, though.  I think you want *some* mechanism to
> > break out, within the method.  If nothing else, it is nice to do things
> > like:
> >
> > 	aPrivilagedMethod
> > 		!PrivilagedEnvironment clamp: [ ".. do some privilaged stuff.." ]
> >
> >
> > But maybe I just haven't thought enough about how to get rid of the last
> > few instances.
> Lex,
> Do you think it's necessary to be able to both statically and dynamically
> access the same variable names, or simply to have some statically bound
> variables that only priviledged methods could access?  If you really
> needed both you could have "Smalltalk" (dynamically bound) and
> "BasicSmalltalk" (statically bound) or some such.
> That is, currently there's no problem (or at least not much grumbling)
> with having an identifier Foo able to be either a class var, or a pool
> var, or a (static) global; instead of adding new syntax, why not just add
> dynamic global as a possibility?

My reasoning was that it is very nice for the static links to be visible
when reading the code.  Actually, in a first pass, methods could be
compiled in either all-static or all-dynamic mode, and I didn't like it.
 Even when running with all privilages (like being root in Unix), it is
nice to have to explicitly ask for extra stuff.  (Similarly, an emerging
style on Unix is for setuid-root programs to spend most of their time
*not* as root, but only to grab root during specific operations.)  Even
in a privilaged method, most of the operations tend to be unprivilaged.

An issue in how you do it, is the question of where the variable
definitions happen.  Right now, of course, there is no organized way to
define global or pool variables in stock Squeak.  I would hate for a
dynamic link to become static, or vice versa, because some redefines a
variable down the line.  Thus being explicit in the syntax seems better
as long as variable definitions are so easy to lose track of or to
quietly get changed.

On the other hand, if there was a more structured way of managing
large-scope variables, then using just a naming convention seems


More information about the Squeak-dev mailing list