Skip to content

Conversation

@jbogard
Copy link
Contributor

@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
Contributor

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
Contributor 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
Contributor

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.

{
Options = options;
Mapper = mapper;
Mapper = new RuntimeMapper(this, mapper);
Copy link
Contributor

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
Contributor 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
Contributor 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
Contributor

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

3 participants