[Squeak-e] Draft Consensus Plan
lex at cc.gatech.edu
Fri Feb 14 17:28:26 CET 2003
"Mark S. Miller" <markm at caplet.com> wrote:
> * What if, as a bootstrapping strategy, Squeak-E starts out not
> self-debuggable and self-malleable, but rather debuggable-by-Squeak-code and
> malleable-by-Squeak-code? In other words, the browsers and debuggers that we
> use to manipulate Squeak-E computation would be written in Squeak, not
> Squeak-E, would be simple adaptations of the browsers and debuggers already
> written in Squeak, and can therefore use the conventional
> non-capability-oriented meta-level power already accessible to them in Squeak.
> For example, by taming (eg, by Andreas' renaming) Squeak-E code would
> not be able to send the real #instVarAt: message to any objects. However,
> Squeak code can, and the existing inspectors do.
Yeah, this certainly sounds like the way to go. I did so with Islands,
and if I understand correctly you have done so with E. I developed
everything in regular Squeak, but could create little sub-Squeaks within
the main one that were restricted. The main point was that final code
would run securely; it's not so important that you can develop that code
in the secure environment.
Incidentally, I still got rid of all the powerful methods in Object by
moving them to ObjectInspector, which is a global in the SystemIsland.
This is what Dean described. I am suspicious of having multiple name spaces,
etc, because now you have different methods being invokable by different
parties. This sounds ACL-ish, and at any rate seems complicated. It is a
nice simplification, if we can manage it, to let people invoke any method at all
on an object they have a reference to. I'm not sure we need to give this up in
order to embed a safe-Squeak inside Squeak. For example, I didn't for Islands.
More information about the Squeak-e