-
Notifications
You must be signed in to change notification settings - Fork 77
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
extension API improvements #511
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,23 +5,42 @@ | |
import java.util.Collection; | ||
|
||
/** | ||
* @param <T> the configured class | ||
* Allows adding annotations to and removing annotations from a class. | ||
* Note that the class is not physically altered, the modifications | ||
* are only seen by the CDI container. | ||
* | ||
* @see Enhancement | ||
*/ | ||
public interface ClassConfig<T> extends ClassInfo<T>, AnnotationConfig { | ||
// TODO remove the type parameter? | ||
// TODO even if ClassInfo has equals/hashCode, ClassConfig probably shouldn't | ||
|
||
// only constructors declared by this class, not inherited ones | ||
// no [static] initializers | ||
public interface ClassConfig extends DeclarationConfig<ClassConfig> { | ||
/** | ||
* Returns the {@link ClassInfo read-only information} about this transformed class. | ||
* | ||
* @return the {@link ClassInfo} corresponding to this transformed class, never {@code null} | ||
*/ | ||
@Override | ||
Collection<? extends MethodConfig<T>> constructors(); | ||
ClassInfo info(); | ||
|
||
// only methods declared by this class, not inherited ones | ||
// no constructors nor [static] initializers | ||
@Override | ||
Collection<? extends MethodConfig<T>> methods(); | ||
/** | ||
* Returns a collection of {@link MethodConfig} objects for each constructor of this class. | ||
* | ||
* @return immutable collection of {@link MethodConfig} objects, never {@code null} | ||
*/ | ||
// TODO specify whether inherited constructors are also included | ||
Collection<MethodConfig> constructors(); | ||
|
||
// only fields declared by this class, not inherited ones | ||
@Override | ||
Collection<? extends FieldConfig<T>> fields(); | ||
/** | ||
* Returns a collection of {@link MethodConfig} objects for each method of this class. | ||
* | ||
* @return immutable collection of {@link MethodConfig} objects, never {@code null} | ||
*/ | ||
// TODO specify whether inherited methods are also included | ||
Collection<MethodConfig> methods(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In this case it may make sense to have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this is something I'm a little ambivalent about. I think we already discussed something similar for annotations and kinda agreed that we'll always return all annotations, including inherited ones. We should probably do the same here. I'm looking at what Weld does for Portable Extensions (because that seems quite under-documented on the Portable Extensions API side), and it works like this:
I guess that kinda sorta makes sense. WDYT? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it makes sense for these methods yes. Although they will be relatively expensive methods to call since materializing all that info could be costly. Micronaut has an extensive querying API for methods/fields that lets you filter methods prior to materializing the actual equivalent of I am not sure if something like this makes sense here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was just thinking about it and I've got two little problems with methods from interfaces. We would include The situation for constructors and fields is rather clear, so I'll draft something and amend the PR. Also, we already had a bit of querying API in |
||
|
||
/** | ||
* Returns a collection of {@link FieldConfig} objects for each field of this class. | ||
* | ||
* @return immutable collection of {@link FieldConfig} objects, never {@code null} | ||
*/ | ||
// TODO specify whether inherited fields are also included | ||
Collection<FieldConfig> fields(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here with |
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No these should just be the declared constructors, inherited ones can be obtained by traversing the super class?