Child modules draft feedback wanted
Vlad Dumitrescu XX (LN/EAB)
Tue Apr 4 09:26:17 CEST 2006
> -----Original Message-----
> From: Richard A. O'Keefe
> I'm proposing "full" modules as units of hot
> loading, and "child" modules as units of encapsulation.
> Being able to split a large module into pieces for editing
> also means that we can extend version control below the module level.
> If someone wants to edit the sorting routines in lists.erl,
> why should they have to check out the mapping and filtering
> functions at the same time?
Just to make sure I understand what you mean. Your child modules would
be similar to traits in OOP, right? I.e. A parametrized[*] set of
methods. In OOP there is a similar dichotomy for classes that should be
both generators of instances (with a lot of functionality) and units of
reuse (small and self-contained).
[*] Parametrization isn't part of your proposal, but I don't see as
unthinkable to use the same mechanism as for 'abstract modules', should
that feature be needed. BTW, does anyone use abstract modules?
 See for example
Quoting from the above,
Traits have the following properties.
- A trait _provides_ a set of methods that implement behaviour.
- A trait _requires_ a set of methods that serve as parameters for the
- Traits do not specify any state variables, and the methods provided by
access state variables directly.
- Classes and traits can be composed from other traits, but the
composition order is
irrelevant. Conflicting methods must be explicitly resolved.
- Trait composition does not affect the semantics of a class: the
meaning of the class
is the same as it would be if all of the methods obtained from the
defined directly in the class.
- Similarly, trait composition does not affect the semantics of a trait:
a composite trait
is equivalent to a flattened trait containing the same methods.
IMHO this looks almost the same as Richard's proposal.
> There is no way of
> marking modules as "private", although the
> -export_to(Module, [F1/N1, ..., Fk/Nk]).
> directive that I proposed many years ago would make this kind
> of thing a lot safer and a lot easier to grasp the structure
> of than it presently is.
This and child modules/traits and the other related things look to me
like they are part of a general module management functionality.
Handling it with module attributes works and is relatively easy
implemented, but feels similar to using records vs abstract patterns - a
little too low-level. It might be useful to try to see if having modules
as first-class citizens and another notation would make anything easier
to understand, use and/or implement.
More information about the erlang-questions