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