behaviours

[Fredrik Linder]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Chandrashekhar
> Mullaparthi
>
> > -----Original Message-----
> > From: Thomas Lindgren [mailto:thomasl_erlang@REDACTED]
> >
> > --- Per Bergqvist <per@REDACTED> wrote:
> > > Still don't see why one would like to use a
> > > -behaviour if there
> > > is no underlying support for it. It will basically
> > > be a no-op except
> > > for the warning. Am I missing something ?
> >
> > * Should we keep around the fact that a module has a
> > behaviour, so that we can check this at runtime?
> > (e.g., gen_server can check that the callback module
> > has -behaviour(gen_server)). module_info/1 can keep
> > track of this easily.
> >
> > (Strictly speaking, this is *not* the same thing as
> > the module exporting the functions required by
> > gen_server :-)

Imho I do not think this is the way to go, since if the actual
behaviour-definition changes when running the system (horrible but
possible), then each module flagged to fulfill the requirements for that
behaviour needs to re-evaluate it's compliance to that behaviour.

I'm not saying the check shouldn't be there, 'cause I'd want it. Though, the
check should rather be dynamic.

Something like:

check_behaviour(Behaviour, Module, all) ->
    case erlang:function_exported(Behaviour, behaviour_info, 1) of
        true ->
            Callbacks = Behaviour:behaviour_info(callbacks),
            F = fun({F, A}) -> erlang:function_exported(Module, F, A) end,
            lists:all(F, Callbacks);
        false ->
            exit({badarg, Behaviour})
    end;
check_behaviour(Behaviour, Module, Functions) ->
    case erlang:function_exported(Behaviour, behaviour_info, 1) of
        true ->
            Callbacks = Behaviour:behaviour_info(callbacks),
            F = fun({F, A} = C) ->
                        erlang:function_exported(Module, F, A) orelse
                           not lists:member(C, Functions)
                end,
            lists:all(F, Callbacks);
        false ->
            exit({badarg, Behaviour})
    end.

Btw, this is a perfect use of the erlang:function_exported/3 function --
perhaps time to change the documentation?

> > * Should behaviours also *require* some functions (ie,
> > yield an error rather than a warning if f/n is not
> > exported)?
>
> I dont think requiring some functions is a good idea. gen_server for
> instance provides three different ways for a server to interact with the
> outside world. If I choose to use only gen_server:call in my
> server, I dont
> want to provide dummy functions and clutter the code. The same
> could be said
> of user defined behaviours.

Still the init function is required for gen_server... So there still is some
use for such functionality.

Guess it'd suffice with a warning though.

> Taking the example of Java interfaces, the Java compiler enforces
> implementation of all functions in an interface which leads to lot of
> bloatware when writing new classes.