Package support in Erlang: Status ?

[Wiger Ulf]

>         -module(com.bigcorp.foo).
>         ...
>         -import(lists).
>         ...
>         f(X) -> ... lists:reverse(...) ...
>
> will call 'lists:reverse(...)' instead of the default
> 'com.bigcorp.lists:reverse(...)'.


I sent a suggestion for a patch to the linter to erlang-patches
the other day (no cc to erlang-questions) though. This patch
makes the linter issue a warning if it encounters e.g. lists:reverse(...),
and there is (a) no '-import(lists).' statement in the module, and
(b) there is no lists.beam (presumably comp.bigcorp.lists) in the
outdir directory.

I've found this to be one of the most common errors related to the
the use of packages. With this warning in place, I feel that adding
-import clauses does not cause me any problems at all, and the
linter will remind me if I've forgotten one.

/Uffe

----- Original Message -----
From: "Richard Carlsson" <richardc@REDACTED>
To: <erlang-questions@REDACTED>; "Mickael Remond"
<mickael.remond@REDACTED>
Sent: den 19 april 2003 12:54
Subject: Re: Package support in Erlang: Status ?


> ----- Original Message -----
> From: "Mickael Remond" <mickael.remond@REDACTED>
> To: <erlang-questions@REDACTED>
> Sent: Friday, April 18, 2003 5:28 PM
> Subject: Package support in Erlang: Status ?
>
>
> > I would like to know what is the current status of packages in Erlang
> >
> > During the last Erlang User Conference, I had the feeling that the use
> > of package for erlang development was here for feedback from the
> > developers but not yet really approved for industrial project.
>
> The OTP people have said that the package system is included for
evaluation,
> and if it turns out that people (i.e., you who are reading this) don't
like
> it, it
> could be removed again. So it's up to you.
>
> So far I've had almost no feedback at all from users, so if you read this
> and
> have tried using packages, then please do let everybody know what you
think!
>
> > I do not feel conformtable yet with the package development as it
> > requires to change the syntax for standard module call (You need to
> > use the prefix . to specify that you are refering to the root
> > package).
>
> The much preferred method is to simply add an 'import' statement at the
> top of the module. So e.g, if you want to call the standard library
'lists'
> module from within a module in a package:
>
>         -module(com.bigcorp.foo).
>         ...
>         -import(lists).
>         ...
>         f(X) -> ... lists:reverse(...) ...
>
> will call 'lists:reverse(...)' instead of the default
> 'com.bigcorp.lists:reverse(...)'.
> The prefix form '.lists:reverse(...)' could also be used, as you mention,
> but this
> is more of a "final resort" solution (if the imported name is already
used),
> or
> could be used if you have a one-shot call to some module and don't feel
like
> adding an import statement, but the -import(...) makes it less error
prone.
>
> So, if you want to move code from the current "flat" namespace into a
> package namespace, you have to:
>
>         1. rename the module, by prefixing a package name
>         2. add an '-import(Mod)' for each non-package Mod that is being
> called.
>
> and that's it. Note that existing code can call package modules without
any
> changes - for example, you can give a module name as
> 'com.bigcorp.mycallback'
> to the good old gen_server, and everything works just as normal.
>
> The only real problem I currently know of is the debugger, which has a
hard
> time
> with the fact that the source file name is not the same as the full module
> name. I hope
> I can fix this for the coming R9C release, or just mail a patch to this
> list.
>
>     /Richard
>