Inherit Event Handlers #34
No reviewers
Labels
No Label
1
13
2
21
3
34
5
55
8
bug
core
could have
duplicate
enhancement
help wanted
must have
proc
question
should have
wont have
L
M
S
XL
bug
bugfix
discussion
documentation
feature
maintenance
postponed
refactoring
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: zdm/event-bus#34
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "f/handler-inheritance"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When registering an event listener, Event Bus recursively walks the entire inheritance tree and looks for event handlers.
Closes #16
@ -224,0 +224,4 @@
## Inheritance
When a superclass or an interface of an event listener defines event handlers, they will be detected and registered by Event Bus, even if they are `private`.
If an event handler is overridden by the listener, the `@Event` annotation of the overridden method is automatically considered present on the overriding method.
Perhaps a new annotation
@ExcludeListener
should be added that instructs EventBus to ignore this method if present. This would allow to override behavior of superclasses that is in some rare cases counter-productive.(But if at all, that is beyond the scope of this PR)
That would be rather difficult to implement given the edge cases. If such a need arises, I will try.
@ -224,0 +225,4 @@
When a superclass or an interface of an event listener defines event handlers, they will be detected and registered by Event Bus, even if they are `private`.
If an event handler is overridden by the listener, the `@Event` annotation of the overridden method is automatically considered present on the overriding method.
If the overridden method contains an implementation, it is ignored as expected.
If the overridden method already contains an implementation in the superclass, the superclass implementation is ignored as expected.
Or do I understand that wrong?
You understood that correctly. There is a difference between the overridden method and the overriding method. One is in the superclass, the other in the subclass.
The topmost comment was intended as a suggestion for the README.
@ -260,0 +272,4 @@
Set<Method> methods = getMethodsAnnotatedWith(listenerClass, Event.class);
// Recursively add superclass handlers
if (listenerClass.getSuperclass() != null)
@ -260,0 +294,4 @@
Class<? extends Annotation> annotationClass) {
return Arrays.stream(enclosingClass.getDeclaredMethods())
.filter(m -> m.isAnnotationPresent(annotationClass))
.collect(Collectors.toSet());
@ -0,0 +33,4 @@
event.increment();
}
@Event
If you now even use priorities you can test whether the priority is always correct.
Also, I think it would be good to explicitly override one of the superclass methods not to do anything.
@ -0,0 +9,4 @@
interface SimpleEventListenerInterface {
@Event
void onSimpleEventInterfaceHandler(SimpleEvent event);
Will an interface-private method annotated with
@Event
be registered?Or should we explicitly disallow that?
There is no reason why it shouldn't be.
Yes, and that's exactly what I find so scary.
In a class, private methods are expected.
In an interface however, no one suspects that there is a private method that is responsible for changing the state.
Well, that would be a very rare case, as the event handler would only work when some class implements the interface and registers itself as an event listener. If such a situation actually arises, it should be made clear how that interface is supposed to be used.
What I noticed, however, is that maybe there should also be a method to not use the whole hierarchy and instead only the current class, i.e. an extra
registerOnly
method.