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