Conversation
|
I was already thinking how would I approach this and I have a different way in mind - one that would not require modifying all of related rules because that is easily breakable by forgetting about it 😊 This approach consists of:
This also avoid potentially expensive operations like get_declared_classes from your PR. |
|
Also, I realized that get_declared_classes does not work because not all analyzed classes might be autoloaded when you start analyzing a trait - autoloading is lazy in its nature. |
|
Good catch - I had actually modified the main Analyser.php class locally as well to run a require_once across each element in the $files array (around line 121), to preload all the classes, and that worked well - of course, I forgot to include in the PR (doh) - that should teach me for working directly out of the vendor/ directory in a project using this and copying files across to the git checkout 😄 . I do like your suggestion better, this one was definitely a bit clunky (I don't like having the 2 diverging paths in each rule file). |
|
Can you try out current master? I implemented the idea here: e59d160 (but use current If you're OK with the results I will release 0.5. |
|
I'll try today and get back to you. |
|
This is great, it works perfect on both the small test environment and on the real code base that I initially found the issue in. Thanks! |
|
Cool, glad to hear that. I've bumped into an issue and will have to fix it before releasing 0.5. I will describe it once I fix it, it will be quite obvious from the code and tests. (Until then, don't be nervous about undefined variables errors in trait methods when the parameter names do not match between the trait and the class.) |
This fixes the issues in #19 that I was complaining about, by parsing over every possible context of the trait use given a code base / file listing.
Please let me know what you think.