BUGFIX: Allow smooth upgrades from var tags

[kitsunet]

Any property that gets reflected for "var" via ReflectionService::getPropertyTagsValues cannot sensibly be upgraded to use type hints only. This addition gives a sensible upgrade path by falling back to reflected type if no "var" tag was available.
In the long run this allows code to seamlessly change from var tags to type hints in all places.

[mhsdesign]

hmmm im not sure that this is a good idea ^^ this is a blanko check for all times ... well never get rid of that 😅 -> unless of course we remove the method ...

... but we have to adjust the call site either way to also handle reflection types and reflection types are not necessarily the same as var types ...

for example a reflection type can be ?Foo while a var annotation expresses nullability via Foo|null (per spec)

Explicit is better than implicit.

[kitsunet]

We can deprecate this method together with tags altogether. I would be fine with that, but changing the usage internally would be breaking, so there is no sensible way out.

[mhsdesign]

but changing the usage internally would be breaking

I dont understand ... you mean adding a second call before getPropertyTagsValues? I dont think thats breaking if it fixes stuff?

Also if we do it case by case we can actually come up with some tests as we'd know what should be affected 😅

[kitsunet]

a second call before getPropertyTagsValues?

If so then AFTER getPropertyTagsValues as is done in this PR otherwise it's breaking again. But I can tackle that option as well.

[mhsdesign]

If we consider this whole tag deprecation and removal serious yes id love that as this ensures another change can later switch the order and eventually log and then remove the legacy tag handling

Or if you are convinced that a utility like this is more correct id rather would like to have it explicit. Some new internal method or a static class which does exactly that and where we later can safely switch the order and also log.

But then again im not sure the whole @var to reflection type mapping works instantly .... what about unions and intersection types ... well definitely need some tests for that in the new places where this works ... do you agree a bit? ^^

[kitsunet]

it's funky either way.
We use our TypeParser utility thingy in some places already to sort things like nullable out. But unions make no sense if you eg. try to configure a type converter. Don't think intersections work for entity relationships....
On the other hand we support stuff like @var array<\My\Package\Class> for type converters and validators, which you cannot replicate with type hints.

need to recheck;)

[kdambekalns]

Also, with e.g. PHPStan there will be useful information in @var for the foreseeable future, so supporting seems like a good idea. The one with "more" information should be used.