Use the PhpDocExtractor in addition to the ReflectionExtractor.

[nick-potts]

I've added the PhpDocExtractor in addition to the ReflectionExtractor which allows you to use the phpdoc to decode data properly. That also works in tandem with the array denormalizer (which I've added to the verbs.php). Its typically default behaviour to include the PhpDocExtractor when the https://symfony.com/doc/current/components/property_info.html#phpdocextractor

I also fixed a bug with the NormalizeToPropertiesAndClassName. If the required parameters count is 0 and there's data, the Arr::has( will return true causing it to fail for no reason. I found that because the DTO class wouldn't serialise for me. I believe the allows us to store a serializable class as a property test isn't actually testing anything, otherwise it should've caught it - I wasn't sure so I didn't delete it.

I also believe now the deserialiser is more robust, the BackedEnum code can be removed and I wrote a test to try prove to myself its working fine - but do as you please with that.

[nick-potts]

.

[inxilpro]

@nick-potts thanks for your patience on this one. I was having a hard time understanding the scope of this PR. Would you mind adding a test that fails when the array denormalizer is missing to demonstrate the value of adding that?

[inxilpro]

See comment.

[nick-potts]

The initial request I made had a bunch of changes that were later removed so the initial comment doesn't make too much sense - the latest is purely stuff that allows the PhpDoc Extractor to work.

The test that was added fails without the array denormaliser - the big benefit from the phpdoc extractor is that it can deserialise arrays using just the phpdoc. From the DTO it tests against, you can see how this works.

/** @var DTO[] $dtos */
public array $dtos = [new DTO]

Without the PhpDoc extractor or the array denormaliser, this property wouldn't get deserialised properly.