hi florin

> Hi stéphane
>
> I have just read the papers on classboxes.
>
> I think they are an interesting and useful concept. I don't think they 
> represent all that we would want from a module system, but I will try 
> to present my view for where they would fit in.
>
> I too believe there is a strong case to be made for being able to 
> limit the capabilities of modules, especially untrusted ones (either 
> because of untrusted origin or because of the experimental nature of 
> their code).
> In general though, as a way of organizing code, many modules that 
> would be dsitinct because of a logical separation/classification do 
> not need to be limited/isolated. Let's say we put collections in a 
> separate module. They will depend on some core module, but they will 
> enjoy the same level of trust, and if for example they add an 
> extension method to Object, there is no need to limit the visibility 
> of that method to the collections module. But this is an artificial 
> example. Let's take my most common use of "overrides": a separately 
> loadable module that contains bug fixes to the base image. Of course I 
> want those fixes visible to everything else in the image.

True
I always thought that we would like to have the two semantics
>
> On the other hand, if we let foreign Croquet code run in our image, we 
> would most likely want to limit its capabilities.
>
> With the above in mind, I think that it would make sense to assign 
> levels of trust to modules and to link the visibility of the changes 
> to the level of trust: if a module has a level of trust equal or 
> greater than that of the modified (or imported, in your terminology) 
> modules, its changes should be visible to the imported modules as 
> well. If not, its bindings should be local.

Interesting idea.;)

>
> Obvioulsy this does not completely solve the security issue, but I 
> think it's one of the necessary steps.
>
> Florin
>
>