-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Resolve Runtime Annotations via Interfaces #15
Comments
Interesting suggestion, basically you want to remove all the annotations from the pojo agent and waive them into using the interface, is that the correct interpretation? I am not really sure for what use cases that is helpful but it should be not too difficult to implement. Could you shortly comment if I understood that right? |
Yes, you understood that right; although not instead of agent annotations, but rather when the agent has none of these annotations. Imagine we have the following agent: Ideally, There is still a discussion to be had about the multiple inheritance problem (what if several implemented interfaces come with a specific annotation? Solutions include ‘first-come-first-serve’, last-found, some kind of merging). |
Sure, I understand want you want to do but I was wondering why to have the annotations in an interface. Has the interface another purpose than providing the annotations, i.e. has the interface users (other objects that invoke methods on it)? Multiple inheritance could be tackled by setting a resolution strategy; maybe requiring the user/programmer to explicitly set one and otherwise fail on incompatible annotations. |
It allows for more flexible creation of objects that can be used in Jadex, and allows for more choices w.r.t. software architecture. W.r.t. resolution strategies; the Spring folks have got this all figured out already with their AnnotationUtils, but I would not recommend adding a dependency on Spring. |
Currently, reflection to retrieve Runtime annotations such as
Belief
andRequiredServices
is done on a class and all its superclasses in theMicroClassReader
and all its Agent/Capability-annotated superclasses in theBDIClassReader
.Would you be open to accepting a PR to extend this mechanism to also work via interfaces?
This would make it possible to have e.g.
, and allow having pretty ‘clean’ agent implementations for the actual classes.
E.g.:
Thanks for the consideration
The text was updated successfully, but these errors were encountered: