[erlang-questions] Erlang way for process-as-library?

[Vlad Dumitrescu]

On 4/25/07, ok <ok@REDACTED> wrote:
> On 24 Apr 2007, at 7:11 pm, Vlad Dumitrescu wrote:
> > Another way to to the same thing is to have separate modules export
> > different interfaces and just delegating to the base module. This can
> > be implemented as a parse transform where a declaration in the lines
> > of
> >   -interface(Base_Module, [Fn/Nn...]).
> > would be expanded to the required function definitions.
> >
> > Alternatively, the base module could contain
> >    -interface(Interface_Module, [Fn/Nn...]).
> > and the Interface_Module module would be generated dynamically in
> > its entirety.
>
> I don't understand this proposal.  I am in general sympathetic to the
> idea of modules having more than one interface.  (This is a key part of
> the ISO Pascal Extended design, and it's also part of Zonnon, the latest
> member of the Pascal/Modula/Oberon family.)  Could we have more detail?

Let me try to clarify with an example.

-module(my_web_appl).
-compile({parse_transform, interfaces}).
-interface(my_app, [init/1, start/0, stop/0]).
-interface(my_rest_service, [get/2, post/3, put/3, delete/2]).
-export([...all of the above...]).
<code>

would generate besides the my_web_appl beam file, two other
(my_app.beam and my_rest_service.beam) whose code would correspond to

-module(my_app).
-export([init/1, start/0, stop/0]).
init(Arg) -> my_web_appl:init(Arg).
start() -> my_web_appl:start().
stop() -> my_web_appl:stop().

and similar for my_rest_service

> > Of course, the base module can still be called directly, but it
> > shouldn't be.
>
> "Shouldn't be" is not as useful, for writing reliable software, as
> "can't be".  The point of adding -export_to is to make some "CAN'T BE"
> guarantees, and any rival which doesn't achieve that misses the point.

I believe in the philosophy of giving power to the programmer and
using convention and best practices to discourage people from shooting
themselves in the foot.

In this particular case, in order to enforce the "CAN'T BE" condition,
one must not forget to encrypt the beam file when compiling, otherwise
it's easy to decompile and add an exported function to the module that
calls the targeted hidden one.

>> This gives me an uneasy feeling: it means that a process should be
>> aware of the possible clients...
>It doesn't mean that at all.  It's not a *general* replacement for
>-export; it is specifically a way of dealing with the case where the
>module designer *DOES* know all the intended collaborators.

Ah, okay. I thought it was meant as a general mechanism. It still
creates a "backwards" dependency between the modules, but if it's
limited to a small cluster of modules it should work.

best regards,
Vlad