Actually, I think I need to be more clear about what I have reservations about.

I am primarily concerned with Modules being given the responsibility of knowing 
explicitly which other modules they are working with.  By analogy, again 
consider classes- we do not force them to know explicitly which other classes 
contain the selectors they are using.  We do not do things like:

	someObject UndefinedObject.isNil Boolean.ifTrue: [ yada yada yada ].

Instead, we merely carry the *expectation* that someObject will understand 
#isNil, and that the result of that expression will understand #ifTrue:.  We do 
not name *where* these methods are defined/specified/implemented/whatever- only 
that we do wish to use them.

Thus, all I want a module to know is what things *it* defines, and which it does 
not.  Again, consider classes- a given class does not have sufficient scope to 
resolve the problem of finding another class with the selectors it is using.  In 
the above example, it does not for instance have explicit knowledge that 
UndefinedObject or Boolean exist, let alone that they happen to define #isNil or 
#ifTrue:.  That's up to the method dispatch mechanism to figure out- that 
mechanism does have sufficient scope to resolve the selector binding.

Thus, while a given module might reference a global called SomeGuy that it does 
not itself define, it would not actually know what sort of animal SomeGuy is, or 
who or what defines it.  But it would know that it needs it, and would post it 
as a needed import.  I do not want it to know that it will, of its own volition, 
  go out across module space to get SomeGuy from SomeModule.  So, that is why in 
Oasis I am pursuing a different mechanism where a different kind of object is 
involved in binding modules together ( I call it a Backplane - think of the 
posted export/import bindings as a bus, and you start to get the picture ).

So, what I am looking at is something along the lines of the following: Modules 
are independent entities with no knowledge of the internals of other modules, 
Backplanes are the means by which modules are "bound" together, modules can plug 
into Backplanes, and Backplanes can themselves plug into "super" Backplanes. 
Thus, I can have just as much hierarchical structure as your scheme proposes, 
but without ( I believe ) the need for any one module to have any explicit 
knowledge of another module's internals.  More to the point, I should be able to 
easily pull a  given Module right out of the backplane, and replace it with an 
entirely different one, without regard to what the other modules may need- the 
Backplane knows when everyone is happy, and why or why not.  ( we'll see when we 
get there, of course - all of my attention has been focused on some analytical 
problems, so this hasn't had as much of my attention ).

The desired significant feature of this is the (percieved) ability to rapidly 
and easily swap out modules in a somewhat module-polymorphic fashion.  Whether 
the above scheme will do this, or Henrik's cannot do this, I cannot guarantee, 
but this is a characteristic which I feel will be strongly desireable.

- les




Simon Michael wrote:
> Hi Henrik,
> 
> Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> writes:
> 
>>from. A module system that isn't hierarchical defies its own
>>purpose. It would just take us from a flat name space to a flat module
>>space, and that ain't very far.
>>
> 
> I don't know if I'm for or against hierarchical modules, but I would
> argue this point. Even a flat module space would be a valuable thing
> (as existence proof I cite the debian package system) and it has the
> advantage of simplicity.
> 
> Regards,
> -Simon
> 
>