Extend Reflection to expose import statements

[Korbeil]

Hey,

Nowadays there is a limit when trying to resolve a type from a phpDoc in PHP, you'll need to get a "context" for the file where the type as been written. Let's make an exemple with a use import combined with the as keyword:

use App\Command\Foo as Command;

/** @var Command */
$command = my_command();

Another example, you have two classes with the same name but in different namespaces: App\Foo and App\Command\Foo

use App\Command\Foo;

/** @var Foo */
$command = my_command();

Considering both theses example, we require to parse the whole file to check for use import statements so we can have context for the phpDoc types within this file.

To solve this issue with Reflection, it would require:

• ReflectionFile an object that describe the content of a file: a list of ReflectionImport and any other stuff within that file (ReflectionClass ...)
• ReflectionImport an object that describe a use statement with a linked ReflectionClass and a local alias when required

I chosed to not use the keyword use within Reflection here because I think it's too much missleading and import has more meaning in that context.

[iluuu1994]

Hi @Korbeil! This information is not readily available at runtime. The use list is only used at compile-time to resolve the symbols used in the current file. Given that we now have attributes, which do use the use list for resolving symbols, I'm not sure anybody is interested in extending doc blocks further. There are existing solutions to this problem. Maybe you could try https://github.com/phpstan/phpdoc-parser. Disclaimer though, I do not know exactly how this library works and whether it can solve your exact use-case.

[Korbeil]

Hey @iluuu1994, thanks for your feedback.
I'm actually aware on how to do this within PHP (symfony/symfony#40457 and more recently symfony/symfony#52510).
I was trying to find a way to solve this within Reflection because current PHP workaround is to use nikic/php-parser onto the file where the phpDoc is and create that "context" from its result (see https://github.com/symfony/symfony/blob/7.1/src/Symfony/Component/TypeInfo/TypeContext/TypeContextFactory.php#L111-L143 for current workaround)

[mvorisek]

related with #8782

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.