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

Flow resolution context to nested mappings #2940

Merged
merged 3 commits into from
Jan 9, 2019
Merged

Conversation

jbogard
Copy link
Member

@jbogard jbogard commented Jan 8, 2019

Fixes #2937

=> _inner.Map(source, default(TDestination), _resolutionContext);

public TDestination Map<TSource, TDestination>(TSource source, Action<IMappingOperationOptions<TSource, TDestination>> opts)
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some replication. It could be avoided by having the called Map methods always receive an optional context parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to add any more optional parameters to the public API, if i can avoid it. Those have backwards compat problems.

The biggest problems were the overloads taking Action<IMappingOperationOptions>. Those really shouldn't be allowed inside an IRuntimeMapper.

One option would be to separate the interface/objects for IMapper and IRuntimeMapper. Only put the things you should be able to do from the outermost mapping API on IMapper, and only the things you can do during a runtime mapping on IRuntimeMapper.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. It's weird right now.

@@ -105,7 +106,7 @@ internal int GetTypeDepth(TypePair types)
public ResolutionContext(IMappingOperationOptions options, IRuntimeMapper mapper)
{
Options = options;
Mapper = mapper;
Mapper = new RuntimeMapper(this, mapper);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an extra allocation for every Map call with context. It could be avoided by having the context privately implement IMapper and return this from the Mapper property. But I see why you might not want to do that :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! I've already introduced a separate object - I'm not sure it's a terrible idea. I'll push a commit to see what it looks like.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK just pushed this. I think it works better - and in the future, we may want to remove the implicit interface implementation and the Mapper property, and clean up the interface to only the things that make sense for doing mappings inside a Map context.

Also we may have to rename this object. ResolutionContext is....a weird name.

@lbargaoanu
Copy link
Member

A minor version bump?

@jbogard jbogard merged commit 36b2be2 into master Jan 9, 2019
@jbogard jbogard deleted the flow-mapper-and-context branch January 9, 2019 15:07
@jbogard jbogard added this to the v.next milestone Jan 9, 2019
@lock
Copy link

lock bot commented May 5, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ResolutionContext lost in nested mapping
2 participants