Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.3".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

If non-promoted constructor parameters are now valid mapping targets, should we also support putting theMap attribute on those as well? Promoted parameters already support it, therefore I believe this should be also possible for non-promoted ones.

Also, one thing I noticed is that with this change a property with the same name as the constructor parameter has to exist, is that intentional? For example, the following code throws an exception, becauseTarget::$name does not exist:

class Target {    #[Map(if:false)]privatestring$nameUpper;publicfunction__construct(string$name)    {$this->nameUpper =strtoupper($name);    }}$mapper =newObjectMapper();$source =newstdClass();$source->name ='John';$target =$mapper->map($source, Target::class);

@frozenbrain nice catch, the PR now covers that case as well. See commite6009b3 for details on the fix.

The issue related tothe following comment:

// this may be filled later on see storeValue

When the property name differs from the constructor argument name, the constructor argument's value did actually not get filled in at a later time. It are the properties that get iterated over later on, which isn't aware of the constructor argument name anymore (as property field had a different name).

Failing check is unrelated.

@soyuka can you help with reviewing this PR?

Thank you@rvanlaak.