best way to reuse the code from an existing rule? #9069
Unanswered
prescriptionlifeline
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Rector\Renaming\Rector\MethodCall\RenameMethodRector does 90% of what I'm wanting but I want it to change
$someObject->oldMethod();
toSomeExampleClass::newMethod()
and it doesn't look like I can do that with that rector or any other for that matter.That said, I can hack RenameMethodRector up to do what I want. Like I can modify the
refactorMethodCallAndStaticCall
method so that after this line:It does this:
That does the trick, however, I don't want to modify files in the vendor/ directory for obvious reasons.
I could copy / paste the contents of RenameMethodRector to a new file and hack the new file up but I'd also prefer not to do that. Like there's a lot of logic in RenameMethodRector that it'd be redundant to duplicate.
I can't extent RenameMethodRector and implement
refactorMethodCallAndStaticCall
to callparent::refactorMethodCallAndStaticCall()
because (1) that method is private and (2) RenameMethodRector is a final class, meaning it can't be extended (although this does beg the question, why is the class final? what problems did y'all encounter that making that class final solved? if there were no such problems then maybe y'all could remove thefinal
keyword?)Another thing that occurred to me is that maybe I could implement RenameMethodRector in a new class. eg.
That gets problematic, however, because I then need to redefine
autowire
and the other public methods from AbstractRector. Like ideally I'd like future proof code and if I just had a from scratch Rector rule new parameters being added to theautowire
method in AbstractRector wouldn't be an issue, but if I redefine it then I'd have to simultaneously make that same change in AbstractRector and then my implementation would only work on the newest version of Rector. And even then, if I'm extended AbstractRector I can't implement theenterNode
method because that method is declared final in AbstractRector.Implementing RectorInterface could work but then, at that point, I'd have to copy all the methods as AbstractRector implemented them, and half my goal here is to re-use code - not copy / cast large chunks of code.
My questions are twofold:
Beta Was this translation helpful? Give feedback.
All reactions