Extending Functionality: gen_server_ext

Chris Pressey cpressey@REDACTED
Wed Mar 19 18:42:01 CET 2003


On Wed, 19 Mar 2003 18:18:48 +0100
"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED> wrote:

> 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.

But surely the client isn't expecting the call to be transformed into a
cast... ??  My vague feeling is that ideally there should be one function,
gen_server_ext:next(), that goes to the same type of handler (cast, call,
info etc) in the next behaver.

> 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.

Very true.

> 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.

Also agreed.

Another question: what are the pros and cons of having to call next_call()
et al, as opposed to returning a value like {next_call, ...} from the
handler, and having gen_server_ext pay attention to that?

> 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

Still before noon here :)

Thanks for the clarification,
-Chris



More information about the erlang-questions mailing list