behaviours

[Fredrik Linder]

> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Wiger Ulf
>
> From: "Thomas Lindgren" <thomasl_erlang@REDACTED>
>
> > If a module has several behaviours, which I *do* think
> > should be possible, a linter should probably check
> > that their required functions do not overlap. In that
> > case, something is likely to be wrong.
>
> This is the main reason why I'm against multiple behaviours.
> The functions _are_ likely to overlap, or differ only in arity.
> Consider for example init(), handle_call(), terminate(),
> which can be found in gen_server, gen_fsm, gen_event.
> The behaviour framework was obviously based on the
> assumption one module <-> one behaviour, and, if anything,
> _encourages_ cloning callback names from other behaviours.

One of the uses I have for behaviours is to maintain knowledge about why a
certain function is exported from a module.

As an example I'd have:

 o One behaviour to list operational functions (start/stop)
 o One behaviour to list administrative functions (set cache size/...)
 o One behaviour for each other functionality (add user/remove user or
permit_user/is_user_permitted or determine user violations (whatever))

In this way I'd say that multiple behaviours are very desireable.

This could of course be put into separate modules, but doing so distributes
the knowledge that I'd like to keep very close together, and is hence not
desireable. It'd only make the code more difficult to read and understand.

Behaviours like the once I've listed here are non-overlapping in role domain
(how is this process started?, how do I change the cache settings?, ...),
while behaviours such as gen_server and gen_fsm have overlapping domains -
they state different behaviours for a common role (what is the general
behaviour of this process?).

In the latter case I agree with Wiger - allow only one behaviour per module,
but in the former case I am not - allow several behaviours per module.

Best
/Fredrik