[erlang-questions] Large-scale Erlang in practice

[Thomas Lindgren]

>________________________________
> From: Tim Watson <watson.timothy@REDACTED>
> ...
>
>But I still think that having a coarser grained scoping/grouping construct than modules would be useful. This is obviously what applications are for, but they're not *first class* citizens in the way modules are. For example, another IMO great benefit that application level scoping of modules would bring is the ability to provide an export directive that makes functions callable from within your application (i.e., between the modules in app123) but *not* by outside callers. From an API design perspective, that would be very nice to have, as I often need to export shared code for use in my application but don't really want external callers to depend on it.

As I recall, the original packages release had semantic problems with atoms used as module names. Has this been fixed?
For example, if memory serves, the following didn't do what one might expect:


-import(org.proj.app.mod, mod).

foo() ->
   M = mod,
   M:start_link().   %% will not invoke org.proj.app.mod:start_link()

(It got more confusing when you passed 'mod' into another scope.)

Best regards,
Thomas