Retrofitting objcaps (was: Capabilities in Squeak)
lex at cc.gatech.edu
Wed Oct 18 23:36:02 UTC 2006
> > The reason for the current approach--i.e. all global references are
> > bound indirectly through the currently active island--is that compiled
> > code can be reused across multiple islands. In retrospect, it would
> > be better to maintain conceptual pruity and simply recompile any
> > reused code.
> A different compilation strategy would still allow compiled code to be
> shared -- by treating these the way other languages treat captured
> outer lexical variables.
Yes, though for what I think you are suggesting, you would want to
have outer variables that are not global -- i.e., nested classes.
So that gives three solutions to the problem of having multiple (for
example) "World" variables. The original Islands turns the global
variable World into an island-scoped variable, with a dynamic lookup
indirected through the current island. This has the advantage that
existing code needs little modification; however, it has the
significant cost that you have to be very careful about which island
is currently installed as the active one. That turns out to be rather
fiddly and error prone.
The nice thing, though, before moving on, is that a "global" variable
reference gives no new authority! Thus, if you are reviewing the code
of a class, you do not even need to look at normal global references.
Instead, you only need to look at "hard-bound" references,
i.e. statically bound references, which are rare.
Anyway, the middle-level solution I propose above is to have multiple
global namespaces, and to recompile classes for each namespace. This
way you can still reuse classes that refer directly to World, but you
have to fiddle with recompiling them. I would try this first, just
because it is so unobtrusive to the existing language and libraries.
Perhaps we should go all the way, though, and explore nested classes.
The only issue there is that it is a major change. Implementing it in
the language is not a big deal, but updating all the browsers and
debuggers and so on looks like a lot of work, especially if you try to
achieve anything like Smalltalk's level of tool quality. Still, maybe
you have to go this far if you want to take the hard line on lexical
scope and get a usable, security-sensible system.
> > More broadly, I still think the object capabilities approach is
> > important and worth giving a good look in any new language. It is a
> > feature you cannot very well add late.
> It has indeed been hard to add objcaps to Squeak after the fact, or
> rather to subtract out the non-objcap parts of the language. (Motto:
> "Don't add security, remove insecurity.") Other efforts have yielded
> varying results.
Thanks for the excellent overview. I was only aware of some of these.
More information about the Squeak-dev