From: Mike Bethany <mikbe.tk@...>
Date: 2011-06-27T00:13:45+09:00
Subject: Re: Single Responsibility Question

--90e6ba5bc087543ee104a69ee199
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the replies guys.

This is a mixin module so I have no control over the listener code. Even if
I did though requiring the listener to queue messages to make the watched
object work properly seems like a really bad idea because you're making
listeners do the watched object's job; namely making sure the watched object
doesn't break. The watched object shouldn't know anything about the
listeners; not even how quickly or efficiently they run their callback
function. If a listener needs to do something that could take a long time it
should probably make sure it is a good citizen and doesn't shutdown
everything (unless it needs to) but the watched class shouldn't know
anything about that. All it should know is, "I need to tell this object that
something happened and this is the method I call on that object to do that."

It's also the DRY principle: if you required every listener to
do something that could be done in one place then you
are unnecessarily repeating yourself.

I am looking at implementing the Actor model though in the Eventable module
for adding and removing event listeners.

Thanks again for the feedback,
Mike

On Sun, Jun 26, 2011 at 3:10 AM, Robert Dober <robert.dober@gmail.com>wrote:

> On Sun, Jun 26, 2011 at 2:22 AM, Mike Bethany <mikbe.tk@gmail.com> wrote:
> <snip>
> Tend to agree with your analysis, even so far that I believe you might
> reconsider where to create the thread.
> The listener would spring into mind. But probably you need some kind
> og queuing as has been pointed out by
> Stephen.
>
> HTH
> Robert
>
> --
> I'm not against types, but I don't know of any type systems that
> aren't a complete pain, so I still like dynamic typing.
> --
> Alain Kay
>
>

--90e6ba5bc087543ee104a69ee199--