Adapt(source, destination) does not work when destination is a C# record

[roohial57]

When using Mapster to map data into an existing object, the mapping works correctly if the destination is a class, but does nothing when the destination is a C# record.

This appears to be caused by record immutability, but the current behavior is not clearly documented and can be misleading.

[DocSvartz]

@roohial57 What version of Mapster are you using?

[DocSvartz]

in 7.4.0 Records in C# is not supported and record type from mapster not equal Records in C# ;

The latest pre-release versions have Records support.
var result = source.Adapt(destinationRecord);

it using "with like modify" and you data should be in the result variable.

[roohial57]

@DocSvartz
When using the overload to modify a record, the record is not changed because records are immutable.
public static TDestination Adapt<TSource, TDestination>(this TSource source, TDestination destination)

Do you think we should just ignore this, or at least throw an error explaining that immutable types cannot be modified?
Alternatively, should it be handled by passing the destination by ref?

[DocSvartz]

@roohial57 Do you expect Records to behave immutably?
In Mapster record types were originally intended to be immutable. When I fixed the problem #537, I save this behavior.

Do you think we should just ignore this, or at least throw an error explaining that immutable types cannot be modified?

In my opinion, we must write this information about different behavior for Records in Wiki.
@andrerav @DevTKSS @stagep What do you think about it?

Alternatively, should it be handled by passing the destination by ref?

What do you mean? This behavior has nothing to do with how the destination is transmitted.

[roohial57]

Ok, that's right.
it's the best solution!

[roohial57]

In my opinion, the signature
public static TDestination Adapt<TSource, TDestination>(this TSource source, TDestination destination)
implies that the data from source is be mapped onto destination.
When destination is immutable and this method is called, no error is thrown to indicate that the mapping did not occur.
As a result, the user may assume the data was mapped successfully, while in fact no mapping actually took place.
And this misleads the user.

@DocSvartz , Of course, your perspective is more comprehensive and inclusive than mine.

[stagep]

@DocSvartz This should be added to the documentation. I will put in some time over the weekend to review the issues where I need to respond. I have to understand what functionality docfx provides but I am sure it has something to handle documentation that is in review and not ready to be published. I am just not sure how granular this control is.

@roohial57 if I asked you how many ones can you put into zero, would you answer zero, or would you answer that this is a mathematical error. I would answer zero because that is the truth. So how many properties can you change on an immutable object? Zero. A mapper can only do what the destination allows it to do. So it was successful at mapping, it just mapped zero properties. If you map between 2 class instances and the classes have many properties but only one property that is mapped because it is of the same type and name, is it up to Mapster to tell you how many properties were mapped? I don't want to open a can of worms but I do see value from having an overload such as
public static TDestination Adapt<TSource, TDestination>(this TSource source, TDestination destination, out int result)
but this could be a long term goal if others see value in this. And if value was seen in this, then it would make an excellent first contribution, something I would consider doing myself. TBH, it sounds fairly rote and something that AI could probably do a large portion of. As long as it broke nothing and had excellent test coverage then it sounds fairly straightforward because you are simply ensuring the chain of results are passed up the chain to the final public method.

Also, the result would not have to be just an int, it could be a MappingResult type that has more than one property,

[roohial57]

@stagep
Your idea is also Correct.
If the destination is immutable, what does the following line do, and what problem would arise if it were removed?

source.Adapt(destination);

When a line of code does nothing and its presence or absence makes no difference,
its existence creates ambiguity.

@stagep By the way, I really like the idea of MappingResult.

[stagep]

@roohial57 I agree with you 100% that there is ambiguity. It is like asking what is zero divided by zero. In mathematics, we say this is indeterminate. In the non mathematical world we would say it is ambiguous. I remember as a child having a physical calculator that would give you the result of 1 but it would flash 1. So it was ambiguous, because it was giving you an answer and an error at the same time. Why 1, because any number divided by itself is one, but any number divided by zero is any number. If that is not ambiguity then I don't know what is ambiguity :) Really enjoying this discussion with you, very constructive. Thanks.

[DocSvartz]

@stagep @roohial57 You are not taking into account the method signature, it does not return void :)

[DocSvartz]

source.Adapt(destination); -> var result = source.Adapt(destination);

source.Adapt(destination);
This returns the mapping result.

And it seems to me that the result may be completely different depending on which Destination Type is used. 🤔