Extending functionality: a practical case

[Vlad Dumitrescu (EAW)]

Hi again,

I thought a more practical approach would be more, erm... practical :-) so I set up to tweak gen_server.erl in order to allow for an implementation spread across several modules. It wasn't very difficult, even if I didn't make it backwards compatible with this quick hack. 

In short, the change allows a gen_server_2 to be started with a _list_ of modules that implement the callbacks. The type of the State argument to all callbacks was modified to be {OldState, ModuleList}. See attached demo.erl.

gen_server_2 handles the new type of State and also provides some new functions: next_call, next_cast, next_init, next_terminate, next_info and next_code_change. These will retrieve the name of the next module to call from the NewState, and call the respective handle_xxx function after stripping down the ModuleList.

If the Module list is to be stored in the process dictionary, the new gen_server implementation will be backwards compatible from a callback module's point of view. Also, it isn't difficult to add functionality for modifying the ModuleList at run-time, thus making this ultimately dynamic. 

Now back to the main questions: Is this functionality needed? Did anyone feel at some time that it would be nice to be able to do this? Now that it's here, does anyone think it can be useful? Or is it just a toy feature?

best regards,
Vlad


-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo.erl
Type: application/octet-stream
Size: 4175 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030311/9200c1a7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen_server_2.tar.gz
Type: application/octet-stream
Size: 6040 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030311/9200c1a7/attachment-0001.obj>