[erlang-questions] hierarchical behaviour doesn't seem to work ?

[Dmitry Kolesnikov]

Hi,

If you are trying to achieve a "polymorphism" then nested behaviours is not a right thing.
It is very difficult to justify when use nested behaviours when not. As an example I have implemented a plugin interface via nested behaviour but it could be done through other way around.


Dmitry



On 13.12.2011, at 19.37, Harald Welte <laforge@REDACTED> wrote:

> Hi!
> 
> I am trying to get some code to work, but I have the feeling that
> hierarchical/netsted 'behaviour' doens't really work quite well.
> 
> Let's assume I want to defined a behaviour, which in turn is derived
> from gen_server.  The name of the module is "my_behaviour".  It exports
> the required "behaviour_info/1" function, and implements all the
> gen_server call-backs.
> 
> Then, I'm creating an actual program, let's call it "client".
> "client.erl" states "-behaviour(my_behaviour)" and implements the
> required call-backs of my_behaviour.
> 
> However, now if the runtime delivers something like a gen_server method
> such as gen_cast/gen_call, etc., it tries to call client:handle_cast()
> instead of the my_behaviour:handle_cast().  And since
> client:handle_cast() is not defined, it will crash the process.
> 
> Is this really the intended behaviour (sic) of behaviour?
> 
> To me, it seems most logical that you would want to implement levels of
> common functionality in a behaviour, and "sub-class" a number of different
> implementations off such a behaviour.  And since all of it should be OTP
> compliant, that custom behaviour itself would  be based on some OTP
> behaviour like gen_server, gen_fsm, etc.
> 
> Any comments?  Am I misunderstanding something here?  Thanks!
> -- 
> - Harald Welte <laforge@REDACTED>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions