Skip to content
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

Support From and To static factory methods #1117

Open
TimothyMakkison opened this issue Feb 14, 2024 · 1 comment
Open

Support From and To static factory methods #1117

TimothyMakkison opened this issue Feb 14, 2024 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@TimothyMakkison
Copy link
Collaborator

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.
var target = new global::Mapperly_gRPC.HelloReply();
target.Message = response.Message;
target.ResponseTime = Timestamp.FromDateTimeOffset(response.ResponseTime);
return target;

See #1107.

@TimothyMakkison TimothyMakkison added the enhancement New feature or request label Feb 14, 2024
@latonz
Copy link
Contributor

latonz commented Feb 18, 2024

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):

TSource.ToTTarget()
static TTarget.Create(TSource)
static TTarget.FromTSource(TSource)
static TSource.ToTTarget(TSource)

I'd split them across two MappingBuilders: ConvertInstanceMethodMappingBuilder and ConvertStaticMethodMappingBuilder.

Hints for a contribution despite the contributing documentation:

  • Create new entries in Riok.Mapperly.Abstractions.MappingConversionType
  • Create new *MappingBuilders, Riok.Mapperly.Descriptors.MappingBuilders.ParseMappingBuilder can be used as an idea how it could work
  • Register the new TryBuildMapping methods in Riok.Mapperly.Descriptors.MappingBuilders.MappingBuilder._builders

@latonz latonz added the good first issue Good for newcomers label Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants