Your own behaviours

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Your own behaviours

chandru
I tried looking at the documentation but couldn't find it - is it possible
for a module to implement more than one behaviour?? I don't have an example
of why I would need to do this but it occured to me that it can be quite
powerful for a process to implement different behaviours. A bit like a class
implementing a number of interfaces in Java.

I haven't programmed much in Java so I dont quite know how useful this
ability is - but if someone has experience with this I'd like to hear what
they think.

cheers,
Chandru

> -----Original Message-----
> From: Gunilla Hugosson [mailto:gunilla]
> Sent: 21 September 2001 13:07
> To: erlang-questions
> Subject: Re: Your own behaviours
>
>
> Hi,
>
> This feature has now been added to Erlang/OTP R8 according to
> an implementation proposal made by Ulf Wiger. Release note:
>
> It is now possible to have the compiler check user-defined
> behaviours and not only the pre-defined OTP behaviours
> (gen_server etc.).
>
> This is done by adding a function behaviour_info/1 to
> the behaviour module. behaviour_info(callbacks) should return
> a list of {FunctionName,Arity} which defines the callback
> functions the behaviour uses.
>
> When a callback module with the attribute
>  -behaviour(Behaviour).
> is compiled, its exported functions will be compared with
> the list returned by Behaviour:behaviour_info(callbacks) and
> a warning will be issued if any callback function is missing.
>
> Note that the user must ensure that the module Behaviour is
> present at compile-time and can be found in the current code
> path.
>
> Best regards, Gunilla
>
>
>
> Lennart ?hman wrote:
>
> > Hi!
> >
> > Mandatory callback functions, among other things, are defined
> > in the module otp_internal. This module is used when compiling
> > modules having -behavior attribute.
> >
> > If you wish to extend your OTP with your own behaviors, otp_internal
> > must (should) be changed.
> >
> > My suggestion is that the functions in the otp_internal are
> changed to
> > look for the "answers" in the generic module corresponding
> > to the behaviour at hand. In this way you do not need to change
> > modules belonging to the original system. But instead only program
> > a set of required functions in any new behaviour you invent.
> >
> > Best Regards,
> >
> > Lennart
> >
> > -------------------------------------------------------------
> > Lennart Ohman                   phone   : +46-8-587 623 27
> > Sjoland & Thyselius Telecom AB  cellular: +46-70-552 6735
> > Sehlstedtsgatan 6               fax     : +46-8-667 8230
> > SE-115 28 STOCKHOLM, SWEDEN     email   : lennart.ohman
>
> --
> _____Gunilla Hugosson____________________________________________
> Project Manager, Erlang/OTP
> Ericsson Utvecklings AB, UAB/S/P OTP Product Development
> gunilla  +46-8-7275730
>



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.



Reply | Threaded
Open this post in threaded view
|

Your own behaviours

Ulf Wiger-4
On Mon, 24 Sep 2001, Chandrashekhar Mullaparthi wrote:

>I tried looking at the documentation but couldn't find it - is
>it possible for a module to implement more than one behaviour??

This has been done in a few instances in the past. One example is
sasl.erl, which implements both an 'application' behaviour and a
'supervisor' behaviour. In the case of sasl.erl, it's labeled as
an 'application' behaviour, so the linter doesn't know to check
for 'supervisor' behaviour compliance.

If one wants to implement multiple behaviours with the new model
for specifying behaviours, it would have to be done in the same
way. I recommend against it. I think one module - one behaviour
is logical.



>I don't have an example of why I would need to do this but it
>occured to me that it can be quite powerful for a process to
>implement different behaviours. A bit like a class implementing
>a number of interfaces in Java.

Yes, but in Java, the class concept is central, and it'd be
awkward to have to define multiple classes in order to support
multiple types of interface. Erlang is structured differently.
Without going deeper into why, I don't think the analogy holds.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|

Your own behaviours

Vance Shipley-2
In reply to this post by chandru
Chandru,

This is an issue I have visited before.  The first time we packaged
an "application" I found it odd that the top module, having behaviour
application, did pretty much nothing but start top level supervisor
which was implemented in another module.  I wondered why the supervisor
couldn't also be the application master.  Looking at the callbacks
which the two behaviours have I saw no conflict.  Then I looked at
OTP for examples and that is just what I found.  Some notable modules
which behave as both supervisor and application master are kernel
and sasl.

Here is the example from kernel.erl:

        -module(kernel).
       
        -behaviour(application).
        -behaviour(supervisor).


I wrote a shell script to find all examples (included below) and
here is the list from R7B-3:

./lib/sasl/src/sasl.erl
./lib/kernel/src/kernel.erl
./lib/mnesia/src/mnesia_event.erl
./lib/mnesia/src/mnesia_sup.erl
./lib/mnemosyne/src/mnemosyne_sup.erl
./lib/mnesia_session/src/mnesia_session_top_sup.erl


        -Vance

Vance Shipley
Motivity Telecom Inc.
+1 519 579 5816


find_multiple_behaviours.sh:
#! /bin/sh
for i in `find . -name "*.erl"`
do
        if [ `fgrep -c "behaviour(" $i` -gt 1 ]
        then  
                echo $i
        fi
done