Personally, I prefer the approach of using the constructor rather than
a factory method to create EventMonitors. And for the trivial case,
the two look nearly identical.
new EventMonitor("blah").fire();
newEventMonitor("blah").fire();
The simpler fire looks useful, though I think it might make sense to
put it on the EventMonitor directly.
EventMonitor.fire("blah"); // Equivalent to new
EventMonitor("blah").fire();
The fluent interface that your build provides is interesting, but it
gets complicated if users need to set the new serializable or locked
flags.
I think maintaining a pleasant and small client API should be a goal
of this project. In the long run, it'll be a lot easier for us if we
can keep the different ways of creating the standard monitors to a
minimum. Therefore, I'd suggest that we limit the number of alternate
ways of doing things unless there is a clear need or advantage.
I also suggest we keep all the varying ways to use a monitor on the
monitor itself. I love the TransactionMonitorTemplate functionality,
but I've grown to wish that it was on TransactionMonitor proper rather
than off in a separate class.
I hadn't thought about using the Builder style for EventMonitors. My
initial reaction is to shy away from it because I've only ever seen it
used as a nearly declarative syntax, and I don't see Monitors as
declarations. Rather, they are things that I create to quickly use. I
mentally compare Monitors to NSTasks (from the Cocoa library), which
are used to firing off external programs through the OS.[1]
1. http://developer.apple.com/documentation/Cocoa/Conceptual/OperatingSystem/Tasks/createtask.html#/
/apple_ref/doc/uid/20000803
--
Doug Barth
_______________________________________________
Mailing list: https://launchpad.net/~erma-core
Post to : erma-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~erma-core
More help : https://help.launchpad.net/ListHelp
