behaviours

[Fredrik Linder]

> > 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.
>
> That might be an argument for versioning of
> behaviours, I think. (In principle, the same is true
> today, except there is no notification that it
> happened.)

Good point. Versioning is definitely desired, perhaps something like:

behaviour_info(callbacks) -> [{Function, Arity}];
behaviour_info(version) -> Version;
behaviour_info(_) -> undefined.

> Though perhaps no notification is needed either? (Or
> one could write an extension of code.erl that does
> such checking.)
>
> Anyway, Getting It Right might take some thought. What
> I had in mind was basically
>
> has_behaviour(M, B) ->
>   lists:member(B, M:module_info(behaviours)).
>
> and the compiler tracking what behaviours were
> declared in M and putting them in the module_info.
> Then the programmers can insert checks that M has the
> right behaviour when they write a behaviour, for
> example, checking before a server is started.

Adding version could look like:

has_behaviour(M, B, V) ->
    lists:member({B, V}, M:module_info(behaviours)).

I just realized there are two points where the behaviour information is
beneficial:

 o at compile time - to notify the code writer/compiler about
non-implemented functions defined in the behaviour(s).

 o at load time - to notify the code loader (person?) about behaviour
mismatch.

The first requires the presence of the behaviour with the correct version,
to verify the function list.

The second requires only a behaviour implementation statement (with
version).

Best,
Fredrik