Hmm.. Tonight I checked this one out. This is a bit tricky. Currently TypeConversions and MethodReferences are considered as different things. Which one to take is left up to the template (is this the right spot?) MethodReference takes precedence over TypeConversion (takes precedence over a simple set, but I guess no conversion would map from a typeX to a typeX).

Now, we introduced the possibility to get from A to C via B. What kind of precedence rules should apply then?

a) first direct mapping method A-->C (for perhaps the user has a special reason, even if C==A).
b) then simple assignment
c) then a conversion from A-->C
d) then 2 mapping methods from A-->B-->C
e1) then a conversion from A-->B and a mapping method from B-->C
e2) then a mapping method from A-->B and a conversion from B-->C
f) then conversions from A-->B-->C (all the way), should we support this?

Opinions?

Now, then about implementing. I started out moving stuff related to resolving MethodReferences and TypeConversions to another class (making MapperCreationProcessor a bit manageable again). But I'm not sure whether the template should decide what to include. Seems that the list above is getting a bit to big for a template. My current thoughts is that TypeConversions and MethodReferences have a common parent, e.g.: ParameterAssignment or perhaps just Assignment (if you take a java perspective) or MappingAssignment (if you take a more MapStruct perspective) and there can be max 2 of them (in all combinations) inside this parent. However, requires considerable refactoring. Ideas? Better names?

Uh oh!

Add conversions to #134 #157

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions