Anthony Hannan <ajh18 at cornell.edu> 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.
> 
> Array and World don't have to be global, they can just be given to
> classes that need them.  For convenience, they can be grouped into
> pools.  Methods would have access only to objects in the pools held by
> its class (and superclasses).  Giving a pool to a class is equivalent to
> giving the class capabilities to the pool's objects.  You can even
> restrict the capabilities by only putting proxies in the pool that only
> understand certain messages like #new (versus #addSelector:withMethod:).
>  I describe this pool concept in my SharedSmalltalk paper at
> http://minnow.cc.gatech.edu/squeak/SharedSmalltalk.

You can use pools, but I still think you want dynamically-bound
variables in the pools.  Just consider World, again.  How do you deal
with it?  It's impractical to pass it around so that it will be in
lexical scope all the time.  Yet, for most security policies, you will
want different sandboxes/islands/vats/whatnot to see different World's. 
And ideally, you'd like to have multiple sandboxes in multiple threads
at the same time, each with it's own World variable.  Can you think of a
solution that doesn't look an aweful lot like a dynamically-bound
variable?

More generally, how do you put together security policies by messing
with the permissions of classes?  It seems against the spirit of
capabilities to give all instances of a class immediate access to some
resource.  It seems like you want to give access to objects, not to
classes.  Giving access to classes sounds a lot like giving access to
programs in an operating system, which has shown to be a problematic way
to implement security policies.


Lex


PS -- having efficient class proxies as you describe sounds great,
though it seems to have a complication if you add or remove or modify a
clas method while a proxy to the class exists.