-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Handle name resolving with PHP-Parser's NameResolver #92
Feature: Handle name resolving with PHP-Parser's NameResolver #92
Conversation
This reverts commit 7d95ce3.
Name resolving of namespaced symbols (such as classes, functions and constants) is now done through PHP-Parser's NameResolver. By using it as an additional node visitor, we add a safe additional layer on top of the collection strategies provided by the symbol-parser package. This also makes the fix introduced with 13fd5e9 obsolete now, as the NameResolver is more accurate.
self::assertCount(1, $symbols); | ||
self::assertSame('My\Namespace\Bar', $symbols[0]); | ||
self::assertCount(2, $symbols); | ||
self::assertSame('Other\Fubar', $symbols[0]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like the TypedAttributeStrategy
now also includes parts of the UseStrategy
as well.
Before the TypedAttributeStrategy
only took care of FullyQualified
nodes.
As far as I understood the NameResolver
now makes every type into a FullyQualified
one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same feeling with this piece of code. From what I understand, the NameResolver
does exactly what you said – it resolves all resolvable names to fully qualified resolved names.
I really like the idea. Since my implementation is kind of "custom baked" :) But it seems to be, that using this, makes some strategies to be kind of "duplicate" in logic. Not saying that it's bad, we probably should just merge it :) |
Thanks a lot for your feedback! Sure, I can take a look at the strategies and check which of them are probably obsolete now. I wanted to make sure you like the idea first before I go deeper into the codebase :) |
I merged it into main for now. After that we can still figure out some future changes 💪 |
Sounds like a good plan. Thanks for merging 🚀 Will provide a PR in the |
Temporary commit to test the behavior of composer-unused/symbol-parser#92. Should be reverted once everything works as expected and a new version of the package is released.
Here we go: composer-unused/composer-unused#460 |
Hi @icanhazstring, sorry for the noise, but I've probably found a better solution than the one introduced with #91. Please let me know what you think about it :)
💡 The current implementation would also require a change in
composer-unused
since the constructor signature ofSymbolNameParser
has changed. I can take care of that as well in case you accept the changes in this PR :)Suggested change
Name resolving of namespace-scoped symbols (such as classes, functions and constants) is now done through PHP-Parser's NameResolver. By using it as an additional node visitor, we add a safe additional layer on top of the collection strategies provided by the symbol-parser package. Usage of the NameResolver resolves the exact same issue I outlined in #91.
now, as the
NameResolver
is more accurate. I reverted the change as part of this PR (see 0a2d5ab).All Submissions:
New Feature Submissions:
Changes to Core Features: