Child modules draft feedback wanted

[Romain Lenglet]

Richard A. O'Keefe wrote:
> I've mentioned "child modules" in this mailing list.
>
> http://www.cs.otago.ac.nz/staffpriv/ok/childmod.htm
>
> is a *draft* description of what I'm talking about.
> The configuration language section is missing entirely.
> The Prolog version of the idea is very sketchy.
> But I think the description of the Erlang version is clear
> enough to be criticised, so if anyone would care to read it
> (remembering that it's a draft) and send me comments, that
> would be a kindness.

Let's specify something more like existing classical component 
models and ADLs:

In the "client" module:

-module(client).
-require(fred, [roast/1,]).
...
dosmthng(Foo) ->
    fred:roast(Foo).

My -require clause is almost identical to your -use_child 
directive, and the module name is not a real module name, but 
rather a "logical" one which scope is limited to the declaring 
module.

And an ADL (yes, the "configuration language" here is in fact an 
Architecture Description Language) would allow to specify the 
dependencies *outside* of the code, as bindings between the 
-requires clauses' logical module names and actual module names.
Just like your proposal, this follows the Principle of Separation 
of Concerns, hence it allows to modify dependencies without 
modifying the code and recompiling.
Modifying dependencies could be done either at compile time or 
run-time (this would be an implementation detail).

For instance:
{bind, client, fred, actualfred}
Would specify that all references to the 'fred' logical module in 
module 'client' must be resolved as references to actual module 
'actualfred'.

Of course, just like you allow several -use_child clauses, 
several -require clauses should be allowed in a module, hence a 
module could be bound to several other modules.

And 'actualfred' would be a normal module.
If 'actualfred' has dependencies itself (as were expressed with 
"To_The_Child" declarations in your proposal), then those can be 
expressed with -require likewise:: (there is no need to 
distinguish between dfferent "kinds of depencencies", and 
between "parent" and "child" modules)

-module(actualfred).
-require(parent, [beef/1]).
...
bar(Bar) ->
    parent:beef(Bar).

And in my simple ADL, it could be bound likewise:
{bind, actualfred, parent, client}

A complete architecture specification would be a list of 'bind' 
records:
[{bind, client, fred, actualfred}
 {bind, actualfred, parent, client}]

I believe that we don't need any more concepts in the ADL so far.
Except perhaps your concepts of replaceable / integrated. But I 
believe that such things should be specified in an ADL spec 
rather than in the code: the spec in the code should be reduced 
to the strict minimal, and anything that can be specified 
outside of the code (typically, in the ADL) should be specified 
outside (Principle of Separation of Concerns...). Extensibility 
of such architectural mechanisms should rely on the 
extensibility of the ADL, not on the module source code syntax.

Actually, I believe that one ADL could not cover all needs, hence 
we could need several ones: we need a simple ADL to cover the 
minimum needs (bindings between modules), but we may need a more 
complex, extensible ADL for the more complex cases.


IMHO, my proposal:
1- is simpler than your proposal: only one new clause is added to 
the syntax (-require);
2- does not distinguish between "parent" and "child" modules: 
such a distinction is not necessary;
3- allows all that your proposal allows.

This is just a simplification of your syntax and concepts.
I hope this it is a step forward...

-- 
Romain LENGLET