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.<br>
<br>
<div class="gmail_quote">On 8 February 2012 16:20, Thomas Lindgren <span dir="ltr"><<a href="mailto:thomasl_erlang@yahoo.com">thomasl_erlang@yahoo.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br><br><br><br><br>>________________________________<br>> From: Tim Watson <<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>><br>
> ...<br>
<div class="im">><br>>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.<br>
<br></div>As I recall, the original packages release had semantic problems with atoms used as module names. Has this been fixed?<br>For example, if memory serves, the following didn't do what one might expect:<br><br>
<br>-import(org.proj.app.mod, mod).<br><br>foo() -><br>   M = mod,<br>   M:start_link().   %% will not invoke org.proj.app.mod:start_link()<br><br>(It got more confusing when you passed 'mod' into another scope.)<br>
<br>Best regards,<br>Thomas<br><br></blockquote></div><br>