[Squeak-e] Draft Consensus Plan

Lex Spoon 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.



-Lex


More information about the Squeak-e mailing list