[erlang-questions] hierarchical behaviour doesn't seem to work ?
Wed Dec 14 06:48:09 CET 2011
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.
On 13.12.2011, at 19.37, Harald Welte <laforge@REDACTED> wrote:
> 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
More information about the erlang-questions