Reflection

[web-fu]

Lately I'm working on a mapping library and I would like to add annotation support.
I used PHP Native Reflection, but it is very inconsistent.
Many functions return false instead of null, there is no way to get annotation directly, fetching types from properties, parameters and return is confusing...
I saw that some libraries (PHPStan, for example) use their own Reflection implementation, so my question is: why there is not a dedicated library?
I'm not sure the scope of PSL project is to include reflection, but I think a standalone standardized tool would be very usefull.
What is your opinion?

[veewee]

Hello,

Have you looked into https://github.com/Roave/BetterReflection ?

I think it solves most of the issues you mentioned.
Currently, I don't have any strong opinions on having a reflection layer in psl.

[web-fu]

Yes, I love it.
But quoting the library:

Better Reflection is NOT suited to runtime usage, since performance is much worse than PHP built-in reflection. If you do not want to do anything that native PHP reflection can't do, then just use native PHP reflection! The "Better" in Better Reflection refers to feature, not speed!

Maybe it's possible to have a coherent library more runtime friendly
Just having annotation support would be great

[azjezz]

I like the idea of having a reflection API in PSL, that is better typed, it seems all good in theory, but implementing something that would be truly type safe is not really possible ( or at least not easy ).

I'll be open to suggestions of how such an API would look like, then we can discuss it further.

[web-fu]

Your implementation look similar to my reflection - related project: https://github.com/web-fu/anymapper, https://github.com/web-fu/php-dot-notation.
I'll try phpstandoc-parser and check if I can have better results.

[veewee]

Those look nice as well, cool :)

I'dd say mine rather aims to act as the base components that can be used by implementations like mappers, dot notation wrappers, ... (Like yours). Other implementations could be encoders, validators, ...

[web-fu]

Last days I updated my reflection library adding support from PHP 8.0 to 8.3, enums and others things.
Documentation is still lacking, but test coverage is quite good.
The only way I see now is to improve further is to test against real-life scenarios

[veewee]

Nice to hear. Quickly skimmed around it:
In reflecta, I was also taking the path of decorating the existing reflection classes. But i'm reluctant to take that path since it feels a bit verbose to me. I'm gonna close that PR and start a new one later:

When using reflection for runtime operations, you mostly just want to perform some very specific actions : take the value of a prop, list all contants, see if a method exists, get all class/property/method attribute ... So to me it makes sense to take a more functional approach which focusses on doing one very specific action per function call. Instead of decoration what already exists, I want to focus on specific actions one would want to apply.

For example:

$values = [];
$publicProps = object_properties($object, property_visibility(Visibility::PUBLIC));

foreach ($publicProps as $propName) {
     $values[$propName] = property_get($object, $propName);
}

Non of these function leak any of the reflection internals. (altough you could create a custom predicate function which would leak the \ReflectionProperty instance in order to make decisions).

This API has some interesting advantages to me:

• It is fully task based : You don't need people to know about everything you can do with reflection, rather how to use it.
• It keeps the hard reflection part away from the end-users.
• You can pass in any custom predicate to filter the result - instead of working with the reflection flags. (although this kinda leaks the reflection part)
• You can't pass both string|object as param. Downside : We need both object_properties and class_properties - which are in big lines the same - but with small nuances like dynamic properties.
• Take for example : object_attributes($object, $predicate) : you can return the initialized object attributes instead of a ReflectionAttribute making it all easy to use for the end users without having to deal with reflection theirselves.
• Error handling: a lot of reflection functions result in a ReflectionExceptions which all need to be dealt with. This becomes a bit verbose, but it's all contained in small functions. (Example 1, 2)
• It's easier to create an immutable API this way (example)

I'm just typing out my thoughts here. Feel fee to counter them : In the end we're all just looking for a good way to deal with reflection :)

[web-fu]

Since most of the Reflection application are atomic you may be right.
If you browse my encapsulation most of the time I return the original result (or the wrapped version of the original result)
My phylosophy writing my library was "keep as much similar to standard PHP reflection as possible" and "keep as strict type as possibile"
Reflection can be hard for newbie, and I wanted to keep the learning curve as flat as possible.
I don't think there is an absolute best in our approach.
I wrote a toolbox that you can use for example to build a task-based, functional, immutable API
I'll try to rewrite some of your examples and see what happens