[erlang-questions] Large-scale Erlang in practice

[Tim Watson]

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.

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:

1. I'd like to minimise the risk of name clashes without having to add a
massive prefix to my module names.

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.

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

<org>_<app>_<module>

nebularis_ioutils_remote_resource_resolver

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.

2. I'd like to export/share functions within an application (or "grouping
construct" of some sort) but not outside it

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.

3. I'd like to have a *simple* way to switch between implementations that
observe the same external interface

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.

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.

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.

Hope that makes sense.

Cheers,

Tim

On 8 February 2012 10:02, Bengt Kleberg <bengt.kleberg@REDACTED> wrote:

> Greetings,
>
> To what extent would something like LACE
> (
> http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html),
> but for Erlang, handle your problems?
>
>
> bengt
>
> On Wed, 2012-02-08 at 02:06 +0100, Tim Watson wrote:
> > 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.
> >
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120208/f5134524/attachment.htm>