theshoeshiner commented on PR #1156:
URL: https://github.com/apache/commons-lang/pull/1156#issuecomment-1913298493
I think even with the use of lambdas the util class offers the convenience
of not having to manage all the listener specifics in regards to error handling
and order (Unless im missing some potential bit of code optimization)? That
management is still incredibly repetitive if you have many event types.
The FileAlterationObserver uses lambdas for iteration, but I think consumers
still cant add listeners via lambdas because the listener interface has
multiple methods. I do think lambdas could be taken advantage of if this
feature was reimplemented to support only single argument events. So your fire
would look like...
`listenerutils.fire(new MyEventType(params...))`
and your consumers could do stuff like...
```
provider.listenerutils.addListener(MyEventType.class, event -> {
...
});
provider.listenerutils.addListener(MyEventType.class,this::handleMyEvent);
```
Basically just replacing the pattern of maintaining a listener interface
with maintaining event type classes.
(That's all off the top of my head so I could be wrong about the
possibilities)
That would eliminate the proxying, but the util class would still handle the
ordering and error handling, much like it does (or doesnt) today. The new
implementation uses more up-to-date language features, and It has some
limitations of it's own, but in the end its just a different way of
accomplishing mostly the same thing, which is just encapsulating your listener
management logic. It would definitely be it's own class though, since its API
would be completely different than this one.
I think the above logic might work better for my usage, allowing consumers
to target specific events, but that still probably doesnt address the question
of whether it's useful enough to belong in commons.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
