10 ms·

A call to Trigger does not call start go routine https://github.com/GianlucaGuarini/go-observable/blob/master/observable.go#L37-L42 https://github.com/GianlucaG

A call to Trigger does not call start go routine https://github.com/GianlucaGuarini/go-observable/blob/master/observable.go#L37-L42 https://github.com/GianlucaGuarini/go-observable/blob/master.... I agree it can be nice to add a check to skip Trigger calls on non-exsisting channles. I don't know how you use the observable patterns but normally you first set you listeners and then you trigger the events, the other way around makes no sense

simoncion 11y ago
> ...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.
- gianlucaguarini 11y ago
  thanks for the constructive hint I will try to do my best
ridiculous_fish 11y ago
The goroutine is created in Observable.On(), but is initially blocked in a select. Trigger() is what "kicks it off" in the sense of unblocking the goroutine, so it can do real work. Apologies that that was unclear. The observer pattern decouples notifiers from observers. Observers may come and go at any time, and whenever a notification is posted, all the currently registered observers see it. If you demand that all observers are added before the first notification, then your notifier has to know which (or how many) observers are going to register! You've coupled your notifiers and observers, which is exactly what we're trying to avoid. Here's a concrete example: the event is the user pressing a key. Keypresses often create a new window or change the focus or something, so you can have new observers added in response to a keypress. So a Trigger() leads to an On(). It does make sense!

simoncion 11y ago

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

gianlucaguarini 11y ago
thanks for the constructive hint I will try to do my best

ridiculous_fish 11y ago

The goroutine is created in Observable.On(), but is initially blocked in a select. Trigger() is what "kicks it off" in the sense of unblocking the goroutine, so it can do real work. Apologies that that was unclear. The observer pattern decouples notifiers from observers. Observers may come and go at any time, and whenever a notification is posted, all the currently registered observers see it. If you demand that all observers are added before the first notification, then your notifier has to know which (or how many) observers are going to register! You've coupled your notifiers and observers, which is exactly what we're trying to avoid. Here's a concrete example: the event is the user pressing a key. Keypresses often create a new window or change the focus or something, so you can have new observers added in response to a keypress. So a Trigger() leads to an On(). It does make sense!