-
-
Notifications
You must be signed in to change notification settings - Fork 916
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
#2947: fix for wildcard bounded values. #2995
base: main
Are you sure you want to change the base?
Conversation
I also had a look at this one when I was analysing it and it was tricky, because on the first step like you've done now it is being fixed. However, I think that if you do |
@Zegveld I really dislike the fix in this PR. It is way to intrusive and changes a lot of things that shouldn't really be affected. I'll give it a go and try to see if I can come up with another fix for this one. |
The one bit I don't like myself about the current change is the "?" comparison bit at the As a result of the changes an parameter at |
All that looks way too error prone. We should create a correct accessor with a correct type and not pass this things down to the |
Seeing as tackling #2070 would indeed mean that the code there would change again, I've done some more rework and moved all the required actions onto the |
I guess I need to dig in to this material as well. I'll try to have a look sometime this week.. |
I believe the current state is the best I can do atm. if you have any idea's for improvements I'm open to them. |
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.
Its a while ago.. but for me this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html was really useful. I'll have a better look at the case soon.
I really do not feel comfortable removing one of the methods from the public interface OtherWildCardInterface extends WildcardInterface {
} @Mapper
public interface WildcardNestedInheritedExtendsMapper {
WildcardNestedInheritedExtendsMapper INSTANCE = Mappers.getMapper( WildcardNestedInheritedExtendsMapper.class );
@Mapping( target = "object", source = "contained.value")
Target map(SourceContainerInherited<? extends OtherWildCardInterface> source);
default String mapToString(WildcardInterface rawData) {
return rawData.getContents();
}
default String mapToString(OtherWildCardInterface rawData) {
return rawData.getContents() + "other";
}
} Or perhaps another raw types that need to be returned in the scope of the currently declared type. There might be some other edge cases where we resolve these things. In addition to that in the if ( returnType.getKind() == TypeKind.WILDCARD ) {
if ( ( (WildcardType) returnType ).getExtendsBound() != null ) {
return ( (WildcardType) returnType ).getExtendsBound();
}
return ( (TypeVariable) executableElement.getReturnType() ).getUpperBound();
} I am confused by that. We check the I'll need some more time to process this changes and try to wrap my head around them |
with I'll move the concerning the Filters bit It however is not true that because Think I'll also add some inline comments as to how and why the code works like this, and which situation is covered by what line. |
…package and renamed to ExtendsBoundMapper and Test.
…unsupported typevar usage with extends.
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.
LGTM.. some naming remarks..
processor/src/main/java/org/mapstruct/ap/internal/util/Filters.java
Outdated
Show resolved
Hide resolved
// in case of '? extends ...' we want to return the '...' part. | ||
return ( (WildcardType) returnType ).getExtendsBound(); | ||
} | ||
// in case of just '?', we want to look at the original methods return type and see if that one has an |
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.
I guess this can only be if the method is generic. Because the getWithinContext
would already have tackled the class defined type-var's right?
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.
That is correct.
/** | ||
* @author Ben Zegveld | ||
*/ | ||
public interface WildcardedInterface { |
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.
I understand that this is the base for a wildcard.. But the interface itself does not contain wildcards. Hence the name is somewhat confusing. Would UpperBound
be a better name?
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.
Or WildCardBase
or just WildCard
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.
went with WildCard
and WildCardImpl
/** | ||
* @author Ben Zegveld | ||
*/ | ||
class WildcardedInterfaceImpl implements WildcardedInterface { |
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.
same here: UpperBoundImpl
?
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.
went with WildCard
and WildCardImpl
Got the given example situation working and all other tests still pass.
Add testcase with super wildcard.typebound
instead ofwildcardextends
.Already created the PR so that the fix is already reviewable. (Only planning on adding more tests not changing more code)
Fixes #2947