Hi Niall, That is an interesting point, thanks for that. I'll keep this in mind as I stretch the leg of this pattern over the coming few days. I can already see your point causing harm, the same thing happens currently with regular signals. Since a signal is the one that ultimately calls upon subscribed methods and functions, it is in the signal class that errors usually gather. I've been looking for a way to solve that, but haven't succeeded yet.
By event handler, you mean have a method that filters all incoming events? Similar to the Qt Event System? I may be wrong, but it seems to me that it would simply move the problem to the event handler, no? For reference, let me post a Python implementation here, so we're all on the same page. The one I'm using, with weak references https://gist.github.com/mottosso/11008554 And a stripped one without fuss https://gist.github.com/mottosso/11008652 On 17 April 2014 12:01, <[email protected]> wrote: > You will have to excuse my brevity and any typos in advance, as I am > writing this on my cell phone. > > If I understand correctly, you want to define how a particular object (the > subject, using your vocabulary) can notify another (observer) of an event, > have the observer take some action, and then return some thing as a result. > > I understand that decoupling the subject from the observer could > appealing, so that you can call any function provided by observer when an > event occurs. (And possibly provide logic inside the request to route the > event to one of many possible functions inside the observer) > > However, I think this particular implementation would cause more issues > than it solves. > > For instance, in the case that a third object wires a subjects event to > the wrong method the observer, and some exception thrown the observers > method. In this case, my stack trace will show that the subject called the > observer, and that an exception was shown. > > A developer would then spend time tracking down where these calls > happened, only to not find anything wrong. They would have to know that > object 3 wired the event, and only upon looking at the code in object 3 > would they find the bug. > > This makes the code a maintenance nightmare. Especially if the maintainer > didn't write the code. > > And I'm all for making maintainers lives easier. > > Secondly, this means that an object does not fully control what it's > response is to an event. > > I am of the mind that an object should explicitly define its behaviour to > events. > > Have you considered using event handlers? > > Observers must satisfy an interface that the subject can call directly, > making maintenance easier. > > Also, the observer then is in full control over what happens in response > to the event. > > Finally, a subject is then able to provide subscribe/unsubscribe > functionality to allow dynamic routing of events to different observers. > > Turns out that wasn't so brief after all. > > On Thursday, April 17, 2014 9:07:10 AM UTC+12, Marcus Ottosson wrote: > > Hey guys, > > > > > > I'm looking for feedback on a programming pattern I've been tinkering > with lately; its a simplification of signalling an event and getting a > result back via another signal, such as when a GUI requests an event to be > performed, but the event it performed elsewhere - most likely a separate > object - and gets an event back from the separate object upon completion. > > > > > > The Request Pattern > > > > > > Let me know what you think. > > > > > > Best, > > Marcus > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/585f7e11-45ba-401a-a533-6811a3c0069d%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAwnCY0AyE6qG%2BdQQSnDN3ZtYVm3hhe4e5isp2pQWoX-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
