[erlang-questions] Large-scale Erlang in practice

[Tim Watson]

On 7 February 2012 22:00, Attila Rajmund Nohl <attila.r.nohl@REDACTED>wrote:

> 2012/2/7, Tim Watson <watson.timothy@REDACTED>:
> [...]
> > Yes but my point about very_long_module_names is not just that it is ugly
> > and painful to type. I can get autocompletion in vim/emacs today so
> that's
> > not the issue. The point is that as the number of libraries/applications
> I
> > am able to choose from increases (and let's face it, they're growing
> fast)
> > I'm increasingly being forced to deal with module name clashes *or* to
> put
> > up with very long names which are distracting to look at - they take
> focus
> > away from the *function* that is being called, which is what *I* want to
> > focus on.
>
> In the AXD301 the module names were prefixed with the subsystem name,
> so for example many subsystems could have a library module with name
> like xyzLib. I guess this was enforced on project level.
>

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.


>
> Honestly, C doesn't have packages either, still applications can use
> dozens of libraries. Even though the situation is not exactly the same
> (in C the internal names can "clash"), the API functions are (in many
> cases) religiously prefixed with the library name. An this worked for
> the last 40 years.
>

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?

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.

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