[erlang-questions] newbie: why c.erl is special?

shiwei xu xushiweizh@REDACTED
Sat Mar 1 05:59:49 CET 2008

I think flat module namespaces is a defect of erlang design.

For example, I write a foo.erl, It works well. But maybe in a late erlang
version (eg. R13B)  also write such  module named  foo.erl. Then,  you can
see  my application goes wrong.

How to avoid things like this? Let's see the following ways:

1. Adjust module searching paths, and let user path (which contains my
foo.erl) take precedence over erlang stdlib/otp path. But, this way can't
always work well. If some other stdlib/otp modules use system foo.erl (not
my foo.erl), Things goes wrong.

2. Write erlang modules always named with a prefix (a fake namespace. For
example, projectname_foo.erl or organization_projectname_foo.erl). This way
really can solve the problem. But, It seems ugly.

Is there a way let's user still can call foo:func (not call foo.erl provied
by stdlib/otp, but my projectname_foo.erl)? I have a suggestion:

Can erlang provide a 'module name alias'? That is, I can rename a module's
name temporarily in a module? For example:

-alias(foo, organization_projectname_foo). %% alias

some_func_call_foo() ->
    foo:func().  %% same as: organization_projectname_foo:func()

Currently I can do this by using the 'define' keyword. For example:

-define(FOO, organization_projectname_foo). %% alias

some_func_call_foo() ->

It works well, but a bit ugly.

On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff <sysop@REDACTED> wrote:

> On Feb 29, 2008, at 14:34, Anthony Kong wrote:
> > If I rename c.erl to something else, the problem goes away.
> >
> > What is special about "-module(c)" ?
>    Welcome to the world of flat module namespaces.
>   The code module is your friend in these circumstances.
>   Look into code:clash() and code:which(module).
>   code:which(c) should return "<base path>/lib/erlang/lib/stdlib-
> <ver>/ebin/c.beam"
> -Matt
> --
> Matt Stancliff            sysop@REDACTED
> AIM: seijimr              iPhone: 678-591-9337
> "The best way to predict the future is to invent it." --Alan Kay
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080301/0d25918c/attachment.htm>

More information about the erlang-questions mailing list