behaviours

[Fredrik Linder]

> From: Wiger Ulf [mailto:ulf.wiger@REDACTED]
>
> As far as I can tell, this discussion is analogous to the single- vs
> multiple inheritance debate in OO.

True

> The main thing that is missing in order to support use of multiple
> behaviours in one module is some remapping facility. One could
> imagine using funs for this in a way that could be transparent and
> add minimal overhead. Example:
>
> -module(ex).
> -behaviour(a).    % expects init/1 and foo/0
> -behaviour(b).    % expects init/1, foo/0 and bar/0
>
> -export([a_init/1, a_foo/0]).
> -export([b_init/1, b_foo/0, b_bar/0]).
>
> -export([behaviour_redirect/1]).
>
> behaviour_redirect(a) ->
>    [{init, 1, fun a_init/1},
>     {foo, 0, fun a_foo/0}];
> behaviour_redirect(b) ->
>     [{init, 1, fun b_init/1},
>      {foo, 0, fun b_foo/0},
>      {bar, 0, fun b_bar/0}].
>
> %% Now we can separate overlapping callbacks and group
> %% the functions in the most intuitive fashion.
> a_init(Arg) -> ...
> a_foo() -> ...
>
> b_init(Arg) -> ...
> b_foo() -> ...
> b_bar() -> ...
>
> The behaviour would have to understand to use
> function_exported(M,behaviour_redirect,1) and use default callbacks
> for functions that are not explicitly redirected. This operation would
> be called when the module is "instantiated". It would entail some overhead
> for behaviours that are not really instantiated (such as mnesia
> callbacks),
> but behaviour redirection would not have to be mandatory.

Yes, either something like this or promptly deny overlapping behaviours.
Maybe even ban using the same function name.

Doesn't the given example require that the caller of each of these functions
also state on behalf of which behaviour it calls them hence making it overly
complex?

Something like:

init(Settings) ->
    A = M:init(Settings) using behaviour(a),
    B = M:init(Settings) using behaviour(b),
    init_state(Settings, A, B).

/Fredrik