behaviours

[Richard Carlsson]

It seems to me that the distinction you're trying to make is between
interfaces (i.e., behaviours - they *are* the same) and what is usually
known as mixin classes (a form of multiple inheritance of
implementations).

For further reading, see e.g.:

http://citeseer.nj.nec.com/flatt98classe.html

http://citeseer.nj.nec.com/246393.html

http://erik.prutser.cx/vu/object_oriented_software_development/Mixin%20Classes%20and%20Layered%20Refinement.pdf

To be picky, I'd like to remark that we're talking about the
behaviour/interface of _modules_, not _processes_, in that a process can
be executing code in different modules at different times, and the
behaviour of a _process_ (if that's what we want to talk about) must be
specified in terms of what messages it receives and sends, and how its
state can change.

In this respect, it is unfortunate that the term "behaviour" was chosen,
but at the same time completely understandable since it was in fact the
behaviour of a process, specifically a gen_server-based server, that was
on the authors' minds at the time.

An interface can describe the set of functions which abstract the
interaction with the process (init, call, cast, terminate), so you don't
have to call 'spawn' yourself, or explicitly send messages with strange
format using the '!' operator, but this is not different from, say, a
module with functions for manipulating a simple database, which turns
out to be implemented using a 'dets' table.

We just don't have a good, general way of specifying real behaviour in a
sufficiently abstract and formal way, except for the code itself. So
meanwhile, we just specify the interfaces and cross our hearts.

Either we live with the fact that interfaces are called "behaviours" in
the Erlang world, or we can introduce the declaration "-interface(...)."
as a synonym. (Unfortunately it doesn't save any typing either way.)

	/Richard


On Tue, 29 Jul 2003, Fredrik Linder wrote:

> > > I've thought about that too, but what is the real difference between
> > > interfaces and behaviours? Is it really possible to
> > > differentiate the two?
> >
> > I think you did put your finger right on the difference:
> >     * defining different (non-overlapping) roles that a process
> > will implement
> >     * defining a one-of-several and rather complex basic
> > functionality of a
> > process
> >
> > I'm not sure I captured the meaning in those phrases, but it's a start.
>
> Yeah, maybe. I'm didn't really grasp that either. :-)
>
> > Maybe if this interface thing would be pushed to the absurd (or
> > almost there),
> > then gen_server anf friends would be defined by composing in
> > different ways
> > several simpler interfaces, for example 'supervisable' (i.e. can
> > be included in
> > a supervision tree),  'upgradeable', 'callable'... Really hard to do a
> > meaningful split, so I won't go further :-)
>
> Yes, wouldn't this be great? :-)
>
> But then again (back to behaviours vs. interfaecs), by just making a small
> shift of view these new simpler interfaces becomes behaviours, since they
> too can be implemented having different behaviours. (Each interface having
> 1+ implementations, each having a different behaviour).
>
> > Using interfaces would probably be most useful in environments
> > with plug-in,
> > dynamic and/or mobile modules - of course one can just use
> > erlang:function_exported, but my feeling is that having a more
> > abstract view
> > could allow for further interesting developments.
>
> This is my feeling too.
>
> Regards
> /Fredrik
>
>

Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://user.it.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham