gen_event init and global names.

[Fred Hebert]

I'm working on Chut <http://bitbucket.org/ferd/chut> (reading the app's
design might be useful), trying to add type specs to my program when I found
I were breaking contracts with the gen_event:start_link/1 and
gen_fsm:start_link/3 functions.

I prototyped my application using the global module directly to register my
processes (I need name distribution), which accepts any term for a name (I
use {atom(), term()}). However, I later on moved it all to a supervision
tree and consequently moved the registration of the processes to the
gen_event and gen_fsm mechanisms, using {global, Name}. This, as expected,
creates a problem because:

   1. the contract is broken - {global, {atom(), term()}} =/= {global,
   atom()}.
   2. I can no longer pass conflict-resolving functions to the global module
   as the OTP behaviors take no argument for that.

So to get the functionality back and respect types, I decided to move in the
global registration to gen_fsm's init function. I'd just pass the supervisor
the name info needed, which would then pass it to gen_fsm:start_link/3,
which would in turn call Mod:init/1 with the right info for it to register
itself. This would work well, without any big apparent problem.

However, this won't hold with the gen_event because there isn't any way to
have an init function running in there without having a handler. I also
can't add a handler without naming the process because I have no direct
access to the Pid. Things go a bit like this:  <some user process> -->
top-level supervisor:add_child --> user_supervisor:start_link -->
my_gen_event:start_link.

I'm a bit lost with it all. The only solution I've found that would work and
be easy to implement would be to use the user_supervisor to find the
gen_event (with supervisor:which_children), then add an event handler whose
role is to do the registration in its own init/1 function.

Does anyone else have a better idea? Ideally I'd like not to change my app's
architecture too much given it fits pretty much every requirements I had
already, except for the type contracts.