> I'm getting cold feet about this change, especially when we're trying to > freeze 2.1
Understandable. > I'm also uncomfortable with the lack of parallelism — when I add > another handler it's added immediately, but a remove happens later. I have an updated patch that fixes the parallelism--adds/removes are both executed immediately. > One problem is that this will break > com.google.gwt.event.shared.HandlerManagerTest.testConcurrentAdd(), > which still assumes that adds are deferred. Just throwing it out, but what about keeping the old HandlerManager impl just as it was (instead of relying on a wrapped SimpleEventBus)? The old impl keeps its old semantics, and SimpleEventBus can behave more intuitively (I assert) without breaking backwards compatibility. SimpleEventBus can also be made simpler by removing any HandlerManager inflicted requirements (e.g. reverse firing, and other already-deprecated methods in an otherwise brand new class.) Also, I was a little surprised to see HandlerManager deprecated, because I thought there was two separate cases here: * app wide events * per-widget/per-object events E.g. I have a Property object, which had a HandlerManager to manage its events. I want to keep per-Property events, but it feels odd to have a Property object have an EventBus inside of it. To me the term "event bus" inherently means application wide. Am I just supposed to get used to using an "EventBus" for per-object events? Thanks, Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
