<div class="gmail_quote">On 7 February 2012 22:00, Attila Rajmund Nohl <span dir="ltr"><<a href="mailto:attila.r.nohl@gmail.com">attila.r.nohl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/2/7, Tim Watson <<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>>:<br>
[...]<br>
<div class="im">> Yes but my point about very_long_module_names is not just that it is ugly<br>
> and painful to type. I can get autocompletion in vim/emacs today so that's<br>
> not the issue. The point is that as the number of libraries/applications I<br>
> am able to choose from increases (and let's face it, they're growing fast)<br>
> I'm increasingly being forced to deal with module name clashes *or* to put<br>
> up with very long names which are distracting to look at - they take focus<br>
> away from the *function* that is being called, which is what *I* want to<br>
> focus on.<br>
<br>
</div>In the AXD301 the module names were prefixed with the subsystem name,<br>
so for example many subsystems could have a library module with name<br>
like xyzLib. I guess this was enforced on project level.<br></blockquote><div><br></div><div>Yes I'm not surprised because everybody (including me) is still doing this today. You can see modules called riak_something and rabbitmq_something and mochiweb_something, etc etc. I have no problem with this, but if people *don't* follow this convention then you run into trouble.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Honestly, C doesn't have packages either, still applications can use<br>
dozens of libraries. Even though the situation is not exactly the same<br>
(in C the internal names can "clash"), the API functions are (in many<br>
cases) religiously prefixed with the library name. An this worked for<br>
the last 40 years.<br>
</blockquote></div><br><div>Yes it can be made to work with, as you put it, religious adherence to coding standards, but C is hardly the poster child for making this stuff easy. In fact C is notoriously annoying when it comes to name clashes, forcing you to write statically linked wrappers to re-export symbols with alternative names and/or mess around with symbol renaming tools. I'm sure there are many clever things that people do in order to make writing assembler code manageable, but that doesn't mean we should consider those good approaches for high level languages like Erlang does it? </div>
<div><br></div><div>I suppose a simple approach to the "long names" complaint might be to write a common parse_transform that appends a configurable "<organisation>_<project>_" prefix to modules during the build and generates a bit of metadata in the application config file. That way I can write my own code in a pithy fashion, have the generated modules *fully qualifies* and have other code that uses it consume the full name. If someone else wants to take advantage of the concise names, they can include the parse_transform in their build and take advantage of whatever `-special_import(...)` directive(s) it makes available for mapping short names to fully qualified module names during the AST transform.</div>
<div><br></div><div>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.</div>
<div><br></div>