stéphane ducasse wrote:

> Hi florin
>
> I really like the quality of your discussion with colin. Thanks for that.
>
>> Here, I am not so sure.
>> As I see it, there are two reasons for having overrides. One is to 
>> offer an automatic resolution for accidental collisions, and as a way 
>> to guarantee that your package _can_ be loaded (without manual 
>> modifications) in its intended state, mentioned above.
>> The other one, that I mentioned in my reply to Dan's message, is for 
>> intentional overrides of something that is known to exist and to be 
>> used in the pre-existing image (either because it is part of the base 
>> image, or because it is part of another, required package). Sometimes 
>> you do need hooks in other packages or in the base image, to attach 
>> yourself to a pre-existing state, and they are not general enough to 
>> justify a "fix" in the base image. Since they are specific to your 
>> package, they should belong as organizational structure to your 
>> package as well, just like normal (non-conflicting) extensions would. 
>> And it's not just about methods. As an example, your module wants to 
>> add some state to processes, so it needs an additional instvar in 
>> class Process. Shouldn't this change to a pre-existing class 
>> definition be contained in your module, be loaded with it, and be 
>> unloaded when the module is unloaded? This is clearly not an 
>> accidental collision, but it does not make sense by itself in the 
>> module originally defining class Process.
>
>
> I agree with you.
> In Classboxes (again I'm not saying that this is the solution) we took 
> the idea that overrides, extensions, state extensions
> were local to the package doing them. I would really appreciate if you 
> could comment on our papers (on the list or privately). I'm not sure 
> that always having the semantics we gave to extensions is the one we 
> want but at least we have a consistent world.
>
> Stef
>

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.

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.

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

Florin