You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Many objects provide static methods instead of constructors for semantic reasons. Unfortunately as Mapperly is unable to use them users have to manually provide wrapper methods. Based upon.
Solution
Mapperly should look for static methods that meet the following criteria:
static methods on the target type named From{SourceType.Name} accepting the source type as a single parameter and the target type as return type
static methods on the source type named To{TargetType.Name} accepting the source type as single parameter returning the target type
Implementation
This should be used as a fallback for if there are no compatible constructors. Should look for the target types From methods before looking for the source To methods.
Perhaps the sources To methods could include non static methods.
I'm not sure to what you are referring by if there are no compatible constructors (are you referring to the ones used by CtorMappingBuilder or by NewInstanceObjectMemberMappingBuilder). IMO this new mappings should try to be built directly after CtorMappingBuilder.
IMO the following signatures could be supported (all ordinary, non-async methods returning TTarget):
Is your feature request related to a problem? Please describe.
Many objects provide static methods instead of constructors for semantic reasons. Unfortunately as Mapperly is unable to use them users have to manually provide wrapper methods. Based upon.
Solution
Mapperly should look for static methods that meet the following criteria:
Implementation
From
methods before looking for the sourceTo
methods.To
methods could include non static methods.See #1107.
The text was updated successfully, but these errors were encountered: