fix(bundle): use map_private_properties when configuring ReflectionExtractor

[nikophil]

configuration map_private_properties was not used to configure service automapper.property_info.reflection_extractor whereas without the bundle, \AutoMapper\Configuration::$mapPrivateProperties is actually used, this PR fixes this.

I had to introduce a way to have several configurations available for the fixture bundle, I'm using KernelTestCase::createKernel() + an additional config file path for this.

waiting for #137

[nikophil]

when making ReflectionExtractor aware of map_private_properties, it has to be set to true for this test to pass.

but it seems wrong to me: even if the property is private, it could be written, because it is in the constructor:

class ClassWithPrivateProperty
{
    public function __construct(
        private string $foo
    ) {
    }
}

WDYT?

[Korbeil]

⚠️ We need to fix this behavior before merging this pull request !

[joelwurtz]

It depends, it only work if we write to it, but not if we read from it

[nikophil]

it only work if we write to it, but not if we read from it

it is indeed IMO the expected behavior, with map_private_properties: false, but that's not what happens

[joelwurtz]

Yes, but not sure we can resolve this easily on our side ?

Does this bug happens because we cannot found the property (not listed) or because we don't find a mutator for it ?

AFAIK, this would require having a different service when we try to get the write mutator on constructor, so we could configure that one to work with private properties

Or do a bug fix in symfony ?

[nikophil]

not sure we can resolve this easily on our side ?

it seems to be a pretty complex problem indeed

Does this bug happens because we cannot found the property (not listed) or because we don't find a mutator for it ?

my understanding of the problem is that we're looping over $this->propertyInfoExtractor->getProperties($target) and it does not return the private property. Then we don't even try to find a mutator.

this would require having a different service when we try to get the write mutator on constructor, so we could configure that one to work with private properties

I got the same feeling: in a "from target" or "source target" mode, we need to investigate a little bit more around constructor's parameters. Or maybe detect properties in a different way: loop over all properties (including private ones) and only keep the ones for which we can find a PropertyWriteInfo thanks to PropertyWriteInfoExtractorInterface::getWriteInfo(). But due to how this is made in property info, this would require two instances of ReflectionExtractor: one which can always access private properties, and another one which is configured with map_private_properties

Or do a bug fix in symfony ?

it seems to me that property info is working correctly here, at least, it does what it is expected to do 😅
Maybe a nice improvement to the property info component would be to leverage the $context argument and allow to override the access flag from there...

[nikophil]

ok, forget about that all :)

I've found a simpler solution

I've roll-backed the current change, and the tests will pass once #137 is merged

[Korbeil]

👍

[nikophil]

would you mind this change? on my computer it greatly improves test performances:

• before: Time: 01:53.571
• after: Time: 01:11.453