[erlang-questions] Why do we need modules at all?

[Joe Armstrong]

2011/5/24 Tim Carpenter <amphibian.ltd@REDACTED>

> (am sending again as this did not seem to get through)
>
>
> Hi all,
>
> I am sticking to the request to not comment on other solutions but present
> my own thoughts...
>
> 1. Some units of code only make sense as a collection. who would use part
> of gen_server in isolation? Well, you could,but to have it separate exposes
> it to modification that could distort the focused purpose of the unit.
>
> 2. some functions have intentionally hidden aspects, private calls etc and
> these again are best left hidden or considered as a logical whole otherwise
> side effects or bloat may occur.
>
> 3. I see no reason why we cannot logically group functions into modules but
> not have the code in there...i.e. the module contains references to
> functions that make it up. this allows logical handling of groups of
> functions for code management and can allow one function to appear in
> multiple modules without code duplication. it also allows one to
> add/delete/replace a function in a module knowing that the source code for
> the other functions have not been touched!
>
>
I checked some numbers.

The OTP release has 1793 modules and in these there are 56317 functions with
different names.
11887 functions are defined in only one module, ie the for 11887 functions
the name alone uniquely
identifies the module. The distribution of functions over modules has a long
tail with strange spikes,
ie most function names are in very small number of modules. But some
function names like handle_call
etc and in a very large number of modules.

Searching for a function using the function name as a key would only lead to
a small number of candidate module if we exclude names like handle_call.

it would be interesting to do this with type signatures ...




>
> 4. naming conventions should be given great thought for simplicity and
> intuitiveness. functions could be in n sets, so a strict hierarchy may not
> suit.
>
> 5. if functions are named as being in modules, the need to provide
> abstraction to the full name may be advantageous, so modulename.sort/3 can
> be used and the module definition translates this to a unique longhand which
> can change over time. The programmer should also be able to use the longhand
> at will using the module as a convenient bulk import/compile vehicle that
> will break at compile time (one would hope). Some form of 'expects...'
> notation could allow a form of protection against inadvertent swapping of
> functions in shared modules altering behaviour.
>
> 6. we may want 3 elements to naming of functions: shorthand, longhand, and
> version, so one can use the latest version of a longhand named function,
> lock to a specific version of a longhand named function or use the shorthand
> latest version or other such combinations.
>

I've been thinking about this for a while - sometimes we need a very precise
name (including an MD/SHA
checksum) othertimes a sloppy name - it depends upon the context.

>
> 7.  n- tier modules - modules of modules? possibly.
>

I think these are "views" not names - we have functions and then different
ways to view them,
in collections of different kinds


>
> Tim
> Tim Carpenter
> Amphibian Ltd
> London
> ENGLAND
> +44(0)7900 888826
> amphibian.ltd@REDACTED
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110524/7feb95bf/attachment.htm>