defining behaviours (Re: Design Patterns for Erlang)
Thu Feb 15 22:57:48 CET 2001
On Thu, 15 Feb 2001, Ulf Wiger wrote:
> On Thu, 15 Feb 2001, Richard Carlsson wrote:
>>There is a recent Master's thesis about design patterns and Erlang:
>> /Richard Carlsson
> Good thesis (I've just browsed it.)
I agree with you. Very interesting indeed.
> I'm currently looking at how behaviours are defined.
> Personally, I don't like the idea of poking into otp_internal.erl
> in order to define a new behaviour. In practice, this means that
> users of OTP can't define their own patterns.
Again I agree. That was one of the first thing that stroke me when reading
> I would like to propose the following:
> - The otp_internal:behaviours() function is simply scrapped.
> If a module defines a compiler directive -behaviour(B), then
> B should correspond to the name of the module implementing the
> - In each behaviour, export a function B:behaviour_info(Category),
> for example like this:
You seem to be right. Maybe the OTP people could enlight us on this point, but
it seems to be a good idea.
> (As some of you know, we at AXD 301 also specify our permanent
> processes in the .app file, and let a central start function take
> care of building the supervision hierarchy. The reason for this is
> to make the process structure more visible.)
Making OTP in general more visible is a good thing. OTP is really improving
your application design, especially thanks to behaviour and should be
> A still open issue is whether behaviours which do _not_ want a
> process should also be allowed? Actually, we have one already:
> application. How would they be defined? Is there a need for
> additional rules?
Or, maybe we could extend the question ?
Does the application need to be a behaviour or should it be something else ?
Really, I have no answer yet.
Mickaël Rémond tel : (33)1.44.42.00.00
Project Manager mob : (33)126.96.36.199.16
15 - 17 avenue de Ségur e-mail :
75007 - Paris web : http://IDEALX.com
More information about the erlang-questions