> ...but normally you first set you listeners and then you trigger the events, the other way around makes no sense Perhaps I might have misunderstood what you'

> ...but normally you first set you listeners and then you trigger the events, the other way around makes no sense Perhaps I might have misunderstood what you're saying, so bear with me: What about the case where you have two, completely independent processes: a event data Publisher, and a Subscriber proxy that proxies Subscription and Event transmissions between your Go program and the rest of the world via -I don't know- Websockets or plain TCP/IP or something. When your Go program starts, you're likely to want start up your publisher immediately. As your program generates reportable events, it'll call Trigger even if noone has subscribed to those events, right? I mean, the whole point of a pub/sub mechanism is for the event producer(s) to not care at all about any of the event consumers... so it sounds to me like the case where Trigger will be called before anyone has called On is common. [0] Anyway. A general thought about safe software design: It's still important to ensure that unusual or incorrect usage of the public parts of an API fail safe whenever reasonably possible. Even the most conscientious programmers will have a brain fart and fail to remember the order in which API functions should be called. If you can detect improper usage, ideally you should signal an error (whether by return value or exception) and leave everything behind the API untouched. Trashing the list of subscribers because someone called On or Off immediately after calling Trigger is surprising and should be something that can't happen. Anyway, good luck with your project. Think of fun and exciting ways that boneheads like me could break it, and make it so that we can't break it like that! :) [0] Back when I used pub/sub mechanisms to attach networked controls to remote computerized systems, it was absolutely a requirement for each of those systems to run the same regardless of whether there were 0, 1, or 100 sets of controls hooked to them.