[erlang-questions] Large-scale Erlang in practice

[Tim Watson]

Not only this, but a number of important tools (including reltool
and cover) don't work properly with the existing packages implementation. I
think it's safe to say that as they exist today they're not usable.

On 8 February 2012 16:20, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:

>
>
>
>
>
> >________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120208/3eb13296/attachment.htm>