Behaviours

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

Behaviours

Alex Peake
Is there, somewhere, a more tutorial description of how to create behaviours?

Alex



Reply | Threaded
Open this post in threaded view
|

Behaviours

Francesco Mazzoli-2
Hi Alex,

OTP behaviors are covered in detail in the Design Principles
documentation at
http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html It
also gives a few good examples. You can complement this with the manual
pages for the different behavior modules. Lastly, you can find tons of
examples of usage of behaviors in the contributions section of the open
directory.

Good Luck,
Francesco
--
http://www.erlang-consulting.com

Alex Peake wrote:

>Is there, somewhere, a more tutorial description of how to create behaviours?
>
>Alex
>
>
>




Reply | Threaded
Open this post in threaded view
|

Behaviours

Alex Peake
Thank you Francesco.

I guess the answer is that there is nothing "of a tutorial nature".

I was looking for more of:

What is a behaviour? When do you need one? How do you build one?

(I saw a quote from Joe Armstrong something of the nature that -- in Erlang you do not need objects
because you have behaviours -- so I wanted to explore what this meant)

Alex

> -----Original Message-----
> From: Francesco Cesarini [mailto:francesco]
> Sent: Sunday, September 08, 2002 6:02 AM
> To: Alex Peake
> Cc: erlang-questions
> Subject: Re: Behaviours
>
>
> Hi Alex,
>
> OTP behaviors are covered in detail in the Design Principles
> documentation at
> http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html It
> also gives a few good examples. You can complement this with the manual
> pages for the different behavior modules. Lastly, you can find tons of
> examples of usage of behaviors in the contributions section of the open
> directory.
>
> Good Luck,
> Francesco
> --
> http://www.erlang-consulting.com
>
> Alex Peake wrote:
>
> >Is there, somewhere, a more tutorial description of how to create behaviours?
> >
> >Alex
> >
> >
> >
>
>
>




Reply | Threaded
Open this post in threaded view
|

Behaviours

Lennart Ohman
Hi,
originally behaviours were developed because their are many
ways to implement a process structure of linked processes
monitoring each other. Monitoring each other in the sence that
you like appropriate actions to be taken if a process terminates
due to a fault. In large project you like all programmers to
use the *same* strategy. It would also be nice if this fault
tolerance stuff was programmed once and for all (by someone
who hopefully knows what he is doing :-). Therefore the code
of a process "using" a certain behaviour is divided into a
generic part and a specific part.

In the generic code these things are hidden, linking, reporting
erronous states, taking some kind of action in the event of
an unexpected process termination etc. You then only have to
write the specific code that will do the task your process is
meant to be responsible for. But since different tasks may
require processes to behave in slightly different manners,
a collection of behaviours were invented.

The specific code must implement an interface to the generic
code. Those functiona are called the call-backs. Take a look
at the man-page for gen_server, which is the simplest behaviour.


/Lennart


Alex Peake wrote:

>
> Thank you Francesco.
>
> I guess the answer is that there is nothing "of a tutorial nature".
>
> I was looking for more of:
>
> What is a behaviour? When do you need one? How do you build one?
>
> (I saw a quote from Joe Armstrong something of the nature that -- in Erlang you do not need objects
> because you have behaviours -- so I wanted to explore what this meant)
>
> Alex
>
> > -----Original Message-----
> > From: Francesco Cesarini [mailto:francesco]
> > Sent: Sunday, September 08, 2002 6:02 AM
> > To: Alex Peake
> > Cc: erlang-questions
> > Subject: Re: Behaviours
> >
> >
> > Hi Alex,
> >
> > OTP behaviors are covered in detail in the Design Principles
> > documentation at
> > http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html It
> > also gives a few good examples. You can complement this with the manual
> > pages for the different behavior modules. Lastly, you can find tons of
> > examples of usage of behaviors in the contributions section of the open
> > directory.
> >
> > Good Luck,
> > Francesco
> > --
> > http://www.erlang-consulting.com
> >
> > Alex Peake wrote:
> >
> > >Is there, somewhere, a more tutorial description of how to create behaviours?
> > >
> > >Alex
> > >
> > >
> > >
> >
> >
> >

--
-------------------------------------------------------------
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


Reply | Threaded
Open this post in threaded view
|

Behaviours

Francesco Mazzoli-2
In reply to this post by Alex Peake
Lots of valid suggestions on behaviors came by in the past posts. To
them, I would like to abstract a little and define "OTP".

OTP consists of three things.

1 Erlang
2 A set of applications (or components)
3 A set of design principles.

These design principles allow you to build an application which exhibit
the exact same behavior as the applications which are part of the
release. In an Erlang system, you create your applications, package them
together with OTP's applications (So that the underlying system does not
differentiate between them), and then use the SASL application to "glue
and start them together".

As Lennart said, part of these design principles involves abstracting
away as much of the common code as possible, leaving only the specific
code to be implemented by the designers. All client - servers for
example follow the same structure. You start them, you stop them, you
send synchronous and asynchronous messages to them. By abstracting away
all of this common functionality into behavior modules, you can

A. Allow all your processes to display a uniform interface to what ever
application is controlling them.
B. Allow your processes to follow a certain protocol (Such as when
applying a software upgrade)
C. Centrally add/control features and support such as debug printouts,
stat monitoring, etc.
D. Allow you to control them uniformly (ex. Start/stop as a whole)
E. Allow a component based terminology

When ever processes follow the same patterns, we say they share the same
behavior. Based on this and all the other emails, I would suggest you
reread the design principle document, as the message it is trying to
portray might be a little clearer.

Give us a shout if it isn't..

Francesco
--
http://www.erlang-consulting.com

Alex Peake wrote:

>Thank you Francesco.
>
>I guess the answer is that there is nothing "of a tutorial nature".
>
>I was looking for more of:
>
>What is a behaviour? When do you need one? How do you build one?
>
>(I saw a quote from Joe Armstrong something of the nature that -- in Erlang you do not need objects
>because you have behaviours -- so I wanted to explore what this meant)
>
>Alex
>
>>-----Original Message-----
>>From: Francesco Cesarini [mailto:francesco]
>>Sent: Sunday, September 08, 2002 6:02 AM
>>To: Alex Peake
>>Cc: erlang-questions
>>Subject: Re: Behaviours
>>
>>
>>Hi Alex,
>>
>>OTP behaviors are covered in detail in the Design Principles
>>documentation at
>>http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html It
>>also gives a few good examples. You can complement this with the manual
>>pages for the different behavior modules. Lastly, you can find tons of
>>examples of usage of behaviors in the contributions section of the open
>>directory.
>>
>>Good Luck,
>>Francesco
>>--
>>http://www.erlang-consulting.com
>>
>>Alex Peake wrote:
>>
>>>Is there, somewhere, a more tutorial description of how to create behaviours?
>>>
>>>Alex
>>>
>>>
>>>
>>
>>
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Behaviours

Chris Pressey
In reply to this post by Alex Peake
On Sun, 8 Sep 2002 09:20:39 -0700
"Alex Peake" <apeake> wrote:

> Thank you Francesco.
>
> I guess the answer is that there is nothing "of a tutorial nature".
>
> I was looking for more of:
>
> What is a behaviour? When do you need one? How do you build one?
>
> (I saw a quote from Joe Armstrong something of the nature that -- in
> Erlang you do not need objects because you have behaviours -- so I
> wanted to explore what this meant)
>
> Alex

To add my spin on this - clarifying or not  :)

What is a behaviour?

Like an object class, a behaviour is a way of generalizing code.  Unlike
an object class, the generalized code is not specialized by overriding
methods, but rather, by supplying callbacks.

When do you need one?

You benefit from using a behaviour whenever you have several different
components which follow a common pattern.  Like a regular module, the
behaviour can encapsulate the common code used by the components.  Unlike
a regular module, the behaviour can define the interface the components
will share, including callbacks that are used by the common code.

Usually, the module which implements a behaviour can be thought of as a
"callback module" - the functions it exposes will be called by the common
code in the behaviour.  (However, I don't think it necessarily stops there
- the behaviour can specify what functions the implementing module should
expose for ANY purpose - although that could be viewed as feature abuse.)

How do you build one?

You write a module which exports a behaviour_info/1 function.  This
function, when called with the atom 'callbacks', should return a list of
{Function, Arity} tuples, which specify the functions that each module
that implements this behaviour should export.  The behaviour_info function
is used by the compiler to ensure that modules which claim to implement
that behaviour, really do.

Anyway, that's my analysis of behaviours based on how they work, rather
than what they're intended for.  I tend to use them much as I would use
abstract base classes if I were to do OO programming - except that the
inheritance tree tends to be much shallower.  A behaviour which itself
implements a behaviour is a rare thing, but occasionally appropriate.

-Chris