Extending Functionality: gen_server_ext

Vlad Dumitrescu (EAW) Vlad.Dumitrescu@REDACTED
Wed Mar 19 18:18:48 CET 2003


Hi,

> So - my impression is that, when you write a behaver for 
> gen_server_ext,
> you typically code it so that when it receives a message it doesn't
> understand, it passes it on to the next behaver with
> gen_server_ext:next_*()
> 
> The other option open seems to be that any unrecognized 
> message would be
> passed along to the next behaver in the chain.  (a bit like 
> gen_event?)
 
> I can see why you would want to go with the first method - it's more
> flexible and more explicit/predictable - but I think there 
> are some minor
> oddities with it being explicit, too - could you accidentally call
> next_cast within a call handler? (then what happens?  Is this 
> "legal"?)

Yes, it should be legal. I think it's a lot like virtual methods: you can ignore the previous implementation, or you can reuse it and select from it what is relevant.

The second option can only handle messages that "fall through" and are not handled at all in the current handler. This is way too rigid, for example if root handler handles {get, Data, Index} and in the new handler I want to only handle differently {get, Data, 0}, I can't.

One could also use regular gen_server and hardcode the next_call to a specific module. This would work in an inheritance hierarchy, but what I would like to do (inspired by Jay) is free composition of independent behaviours.

I hope that what I wrote makes sense. Test is starting to dance before my eyes, so I'm on my way home now. :-)

Best regards,
Vlad



More information about the erlang-questions mailing list