IIRC Dr Richard O'Keefe has suggested something very similar to this approach. I think it is pretty much exactly what I want, especially given that you don't have to use oodles of sub-directories to structure the code. I'm perfectly happy having all my .erl sources under one folder versus the java debacle of a subfolder per package.<div>
<br></div><div>I guess I don't fully see how this resolves the name clashing problem, but then I'm not that familiar with Eiffel or LACE. The laundry list for me then, looks a bit like this:<br><div><br></div><div>
1. I'd like to minimise the risk of name clashes without having to add a massive prefix to my module names.</div><div><br></div><div>In practise, even if I prefix with my application/library name there is a small change that someone else will come up with the same name and it might be necessary as a third party to use both dependencies (my foobar library and their foobar application) in order to access useful functionality that would take a long time to build from scratch.</div>
<div><br></div><div>To avoid this situation fully, I've got to append my organisation/company name *and* application name to all modules then. Some modules require more than one *part* to their name, therefore I end up with crazy names like</div>
<div><br></div><div><org>_<app>_<module></div><div><br></div><div>nebularis_ioutils_remote_resource_resolver</div><div><br></div><div>I want to get away from having to put org + application in the module name somehow, and if something like LACE does this then great.</div>
<div><br></div><div>2. I'd like to export/share functions within an application (or "grouping construct" of some sort) but not outside it</div>
<div><br></div><div>I need to export xoa_qa_stats_optimiser:sync_metadata/2 in order to use it in my application, but I *do not* want someone else's code to be able to call it. I know there is a proposed -export_to(...) directive, but that's a pretty fine grained approach and having to explicitly specify which modules I'm willing to share code with looks like a maintenance headache to me. </div>
<div><br></div><div>3. I'd like to have a *simple* way to switch between implementations that observe the same external interface</div><div><br></div><div>For me, this could be as simple as being able to switch between modules that implement a custom behaviour. I think this plays into the same space as the recent discussion on this list about unifying the interfaces for dict/orddict/sets.</div>
<div><br></div><div>I don't really know what the *best* solution to this looks like, but I guess what I'm after is an approach that *encourages* people to provide (or conform to) a common interface so that I don't have to rely on macros or worse, recoding my modules, when I switch from sets to ordsets, log4erl to lager or even mochiweb to misultin.</div>
<div><br></div><div>I suspect that (3) is a bit out of place in this discussion, but I've dropped it in as all three of these issues make it harder to design an API that people can rely on and/or consume other people's APIs. As the level of code sharing in the Erlang/OTP world increases, this is becoming more of an issue at large.</div>
<div><br></div><div>Hope that makes sense. </div><div><br></div><div>Cheers,</div><div><br></div><div>Tim</div><div><br><div class="gmail_quote">On 8 February 2012 10:02, Bengt Kleberg <span dir="ltr"><<a href="mailto:bengt.kleberg@ericsson.com" target="_blank">bengt.kleberg@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
To what extent would something like LACE<br>
(<a href="http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html" target="_blank">http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html</a>), but for Erlang, handle your problems?<br>
<span><font color="#888888"><br>
<br>
bengt<br>
</font></span><div><div><br>
On Wed, 2012-02-08 at 02:06 +0100, Tim Watson wrote:<br>
> On 7 February 2012 22:00, Attila Rajmund Nohl<br>
> <<a href="mailto:attila.r.nohl@gmail.com" target="_blank">attila.r.nohl@gmail.com</a>> wrote:<br>
> 2012/2/7, Tim Watson <<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>>:<br>
> [...]<br>
> > Yes but my point about very_long_module_names is not just<br>
> that it is ugly<br>
> > and painful to type. I can get autocompletion in vim/emacs<br>
> today so that's<br>
> > not the issue. The point is that as the number of<br>
> libraries/applications I<br>
> > am able to choose from increases (and let's face it, they're<br>
> growing fast)<br>
> > I'm increasingly being forced to deal with module name<br>
> clashes *or* to put<br>
> > up with very long names which are distracting to look at -<br>
> they take focus<br>
> > away from the *function* that is being called, which is what<br>
> *I* want to<br>
> > focus on.<br>
><br>
><br>
> In the AXD301 the module names were prefixed with the<br>
> subsystem name,<br>
> so for example many subsystems could have a library module<br>
> with name<br>
> like xyzLib. I guess this was enforced on project level.<br>
><br>
><br>
> Yes I'm not surprised because everybody (including me) is still doing<br>
> this today. You can see modules called riak_something and<br>
> rabbitmq_something and mochiweb_something, etc etc. I have no problem<br>
> with this, but if people *don't* follow this convention then you run<br>
> into trouble.<br>
><br>
><br>
> Honestly, C doesn't have packages either, still applications<br>
> can use<br>
> dozens of libraries. Even though the situation is not exactly<br>
> the same<br>
> (in C the internal names can "clash"), the API functions are<br>
> (in many<br>
> cases) religiously prefixed with the library name. An this<br>
> worked for<br>
> the last 40 years.<br>
><br>
> Yes it can be made to work with, as you put it, religious adherence to<br>
> coding standards, but C is hardly the poster child for making this<br>
> stuff easy. In fact C is notoriously annoying when it comes to name<br>
> clashes, forcing you to write statically linked wrappers to re-export<br>
> symbols with alternative names and/or mess around with symbol renaming<br>
> tools. I'm sure there are many clever things that people do in order<br>
> to make writing assembler code manageable, but that doesn't mean we<br>
> should consider those good approaches for high level languages like<br>
> Erlang does it?<br>
><br>
><br>
> I suppose a simple approach to the "long names" complaint might be to<br>
> write a common parse_transform that appends a configurable<br>
> "<organisation>_<project>_" prefix to modules during the build and<br>
> generates a bit of metadata in the application config file. That way I<br>
> can write my own code in a pithy fashion, have the generated modules<br>
> *fully qualifies* and have other code that uses it consume the full<br>
> name. If someone else wants to take advantage of the concise names,<br>
> they can include the parse_transform in their build and take advantage<br>
> of whatever `-special_import(...)` directive(s) it makes available for<br>
> mapping short names to fully qualified module names during the AST<br>
> transform.<br>
><br>
><br>
> But I still think that having a coarser grained scoping/grouping<br>
> construct than modules would be useful. This is obviously what<br>
> applications are for, but they're not *first class* citizens in the<br>
> way modules are. For example, another IMO great benefit that<br>
> application level scoping of modules would bring is the ability to<br>
> provide an export directive that makes functions callable from within<br>
> your application (i.e., between the modules in app123) but *not* by<br>
> outside callers. From an API design perspective, that would be very<br>
> nice to have, as I often need to export shared code for use in my<br>
> application but don't really want external callers to depend on it.<br>
><br>
><br>
<br>
</div></div><div><div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>
</div>