[erlang-questions] Avoiding boilerplate code when using gen_server

Tim Watson watson.timothy@REDACTED
Wed Mar 21 13:22:16 CET 2012


That sounds horribly complicated and I always hated corba. What problem exactly are you trying to solve here? Is it

(a) the API function simply passes its inputs verbatim to gen_server:call/2 and therefore you don't want to have to bother writing it by hand
(b) the API function is transforming its inputs before passing them to the server and you'd prefer to write this declaratively
(c) some other issue?

Replacing an API function in the same module as a gen_* callback function seems to me to be several orders of magnitude simpler than an IDL that magically generates 2 modules that eventually end up calling your 'backing' module somehow. Here's what I'd consider doing to remove gen_server boilerplate.

1. write a parse_transform that generates and exports default implementations for any missing callbacks (so that cast/info/terminate/etc are optional)
2. write a parse_transform that generates API functions (with some optional parameter transformation/mapping support) based on either some -spec records or something similar

You can see an example of something similar to (2) in https://github.com/hyperthunk/delegate which uses https://github.com/hyperthunk/annotations. All in all - and I speak as both an OCaml and Erlang programmer here - using compile/build time code generation feels much more natural that trying to shoehorn an IDL into the problem space.  

On 21 Mar 2012, at 11:48, Torben Hoffmann wrote:

> Hi,
> 
> I was sitting with a co-worker - who is proficient in OCaml and lots of other stuff and he is now learning Erlang - and then he comes up with a good question on the amount of boilerplate code when implementing a gen_server.
> 
> From the API functions you call out to gen_server:call/2 and on top of that you need to implement a handle_call/3 function clause that matches whatever format you used for wrapping the incoming message.
> 
> The question was: why don't you use an IDL (Interface Definition Language) approach instead of writing all that code that has to match up in order to work?
> 
> So the idea would be to write a my_server.idl file and from that generate two files:
> my_server_stub.erl
> This holds all the public APIs that clients may call.
> It calls my_server_skeleton as dictated by the IDL file.
> my_server_skeleton.erl
> gets all all the calls from the my_server_stub and calls my_server.erl
> The job then is to implement my_server.erl according to the type specs derived from the IDL file.
> Has anyone looked into this before?
> I have tried searching for it, but since IDL is so tightly coupled with CORBA I didn't really find anything but the ic application from the Erlang/OTP distribution.
> Cheers,
> Torben
> -- 
> http://www.linkedin.com/in/torbenhoffmann
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120321/e1581903/attachment.htm>


More information about the erlang-questions mailing list