On 9 mars 07, at 09:16, Andreas Raab wrote:

> It depends on what you mean by "absolutely forbid to mess each  
> other up". What I would expect from the "perfect" module system is  
> to allow me the formulate the equivalent of both, saying "I want  
> these two modules on different computers", in other words  
> "perfectly isolated" or alternatively to specify "I want these  
> modules to affect each other", in other words "patch module X with  
> module Y". Both are perfectly reasonable, and I simply don't get  
> why you completely disregard the former in favor of the latter.  
> There is *nothing* utopian about it - I run different versions of  
> modules on different computers all the time and I patch modules  
> with others all the time. And they communicate with each other all  
> the time.

At berne guys have been working on changeboxes: having multiple  
versions of a module running in the same image, and I'm trying to  
digest what I would gain to be able to do that. Because I could build  
applications as on my mac that uses different version of components  
without
having to have them all at the same time in the same applications.

Did you encounter cases where you would have like to have different  
versions of the same component/modules running in the same image.

>> Believe me, I do not mean to beat up on your simplification here.
>> It's just a simplification.  Perhaps, though, if you try to be more
>> precise here, then there is a deeper understanding to be had.  What,
>> precisely, does it mean for modules to allow *limited*  
>> interaction, as
>> opposed to the extremes of non-interaction or blatantly stepping all
>> over each other?
>
> I would define "limited interaction" as: Limited to *explicit*  
> interaction, e.g., sending messages requesting services contrasted  
> with *implicit* interaction, caused merely by loading a code base  
> that has an (unintended) side effect on another module. In other  
> words, if module A uses a public API to tell module B it wants  
> "Foo" to mean "Bar" that is much more acceptable than the effect  
> that merely loading A has the effect of "Foo" meaning "Bar" (the  
> simple reason being that module B can deny the request if it is  
> explicit; and that other modules are aware that Foo may mean Bar  
> and can guard against that possible problem).

Indeed.

Stef