John Murph wrote:
I have my latest iteration up on GitHub (at
[email protected]:jmurph/gradle.git branch listener_manager). I (think
I) did everything you requested except
1) I left the StandardOutputListener and StandardErrorListener stuff
combined into a single StandardOutputListener because it just seems
like those are really one concept and having a single listener made
more sense to me.
There's actually 2 concepts here:
- The type of event being received. In this case, we're receiving log
message events.
- The source of the events. In this case, there's 2 sources, namely
stdout log messages and stderr log messages.
The problem with using a single interface for these 2 concepts is that
you statically bind the concepts together. This forces every listener
implementation to deal with the source, even if when doesn't care. For
example, a logging listener which just appends all logging messages to a
text panel must deal with both stdout and stderr events, even though it
does not care about the distinction. This makes it more difficult to
write reusable, composable listener implementations that you can wire
together (dynamically) in different ways.
Another problem with static sources in the listener interface is that
you can't change the set of sources without changing the interface. Or
introducing another, very similar, interface. The set of sources we care
about are quite likely to change. For example, we might want to add some
way to receive all the logging events generated by Ant, regardless of
whether they end up on stdout or stderr. Or perhaps all logging events
generated at info log level. Or perhaps the stderr logging events
generated by the build script.
As a general pattern, I think we should provide small listener
interfaces with maybe 1 method, or possibly 2 methods for a
started/completed type event stream. The interfaces should not encode
the source in the names of the methods (as a parameter of the method is
fine). A listener can pick and choose which of these interfaces it wants
to implement. This makes us resilient to change, and allows listeners to
be composed from reusable pieces.
2) I left DefaultInternalRepository taking a ListenerManager in it's
constructor. I think this is better, but if you still disagree it's
two seconds to change it back.
I don't feel too strongly about this. It's fine how it is.
Other than that, I went ahead and changed things. If I missed
anything, just let me know. If not, you can commit it or let me know
and I can get Steve to do so. (Sorry if I'm being ornery about these
two issues, but as the scorpion said to the frog "it's in my nature...")
P.S. Should I start using the "pull request" feature of GitHub to
notify you of these kinds of things? That would help keep me from
polluting the gradle-dev mailing list, but then I'm not sure who I
would notify, "gradle", "Adam" or "Hans"...
Personally, I think the mailing list is the best place, but I don't
really mind how we do this.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
