What about conflicts between modules?


	links to this page:

Last updated at 2:38 pm UTC on 16 January 2006

No conflicts between modules

Since Modules strictly are just collections of definitions, ie. "dead code", in principle there cannot be such a thing as conflicts between modules. If application A loads and uses module Morphic1.0, and application B has Morphic2.0 loaded, these can be present in the image at the same time without problems, if they are treated as different modules: if M1 defines Morph, and M2 also defines the same name Morph quite differently, then no problem really, these are in different places and there is no conflict.

I don't understand this statement. If a module is just a bundle of definitions, I have to be able to access those definitions somehow in order to use them. This means that some names have to be defined. What if two modules define the same name (e.g., both define Morph, but in different ways. Why is that not a conflict?

I don't think that you can get away from this by saying that each module defines its own namespace, for example, that there is no name

Morph

but only

UI Morph

. If I am to be able to make use of that namespace (UI), then at least one name outside of the namespace must be defined too. What if two modules conflict by defining the same name in the importing namespace? In other words, if I can't just say

Morph

, but have to say

UI Morph

, doesn't that just move the potential for conflict from the name

Morph

to the name

UI

? (apb)

Component conflicts

However, in practice, when you run these modules, the programs defined by the "dead code" may be in conflict: while two different definitions of HandMorph are just fine, what happens when both of them are running, for example, if both start to process input events? These are not conflicts on the code level (modules), but on the running code level, i.e., components.

I don't see that this has got anything to do with Modules at all. I can get exactly the same problem without any modules if I create two HandMorph instances and they both start to process events. Or two instances of

true

, for that matter. The solution is not to do this! One can build checks into the code (as in True class new), but since all code can be changed, in the end I can hang myself if I try hard enough. (apb)

So this is really conflicts on the component level, but in practice you need to handle component conflicts somehow. Still, this shouldn't be too hard. The easiest solution would be to simply (and only) consider different versions of the same module as being in conflict with each other. However, the jury is still out on whether this will be enough.

Replacing a (version of a) module with another

Unlike regular modules, DeltaModules change a base module, and thereby do give rise to conflicts in the defined code itself. For the same reason, DeltaModules can be un/installed, but the un/install operation has no meaning for regular Modules.

However, installing a DM is equivalent to replacing one version of a module with another, ie. the original version of the base module with a new one.

If we would only allow one version of a module to be "installed" (as opposed to loaded) at one time, somehow disabling the unistalled version, then we would have the equivalent of simple component conflict resolution.

(hg)