Creator refactoring modifies Qt library headers
-
@soroush - I have a question for you:
If you are correct, then why isn't refactoring modifying all QWidget derived classes, which are quite a few more than the ones I get modified, as you claim it should? After all, I am refactoring a virtual method, and thus all of its instances should be refactored?? Instead it only modifies the classes, used in the inactive open project. What is your metaphysical theory on that kind of behavior? ;)
-
But if "out of project scope" is the intended behavior of refactoring, doing so will break all the non-visible classes since the base virtual method will effectively disappear?
Not to mention that if was indeed intended for refactoring to be able to affect classes at the library level, it should not only affect all headers, regardless if they are visible or not, but also the cpp files, because otherwise everything will break.
Or maybe such a behavior for refactoring was not intended in the first place, or if intended, was not implemented thoroughly enough?
Fact is refactoring ... needs some more refactoring if it is intended to be used outside of a project scope on global level. Otherwise it obviously breaks the code.
In short - out of project scope changes cannot be made in the blind as refactoring currently operates.
-
I personally maintain that "out of project scope" is not (nor was it ever) the intended behavior, but rather is the bug that needs to be addressed. Developers want to refactor the code in their project, not the entire development API.
A bug report has already been filed... it's done.
Why are we even still talking about this? Just let it go... really... just let it go...
Please call off this stupid pissing match, or take it to email, or something...
[I think I need to call it a night. I'm unsubscribing to updates. Where's the Tylenol?]
-
@mlong - what's the sweat, I think we are back at the level of civilized discussion, I got his point and now we are iterating over it.
If this is indeed a bug, it is a product of the "lack of intelligence" in refactoring, because right now it is literally blind. It should be improved upon by either:
- making it intelligent enough to keep it to the active project. Note I say "active project" rather than "open projects"
or...
- making it intelligent enough to know better when it steps out of active project scope. Which is arguably a good idea to begin with, since the little benefit this approach has is completely overshadowed by the disruption to APIs it can cause.
In short, I'd rather maintain my position that the API should be immune to refactoring when it is being used, and should only be ... refactorable?!? if it is the active project.
This can be achieved by constraining refactoring from tracking hierarchies to project level and no deeper. Which while simple, may not be easy to do, since I suspect refactoring borrows its "intellisense" from a source that is shared between other functionality, e.g. refactoring logic should be reimplemented.
This way it would do what I expected it to do when I found this "bug" - change the method name for MyLineEdit from mousePressEvent to mouseReleaseEvent, so it corresponds to QWidget::mouseReleaseEvent, instead of changing every visible to Creator QWidget derived class' press even to a release event.
-
bq. what’s the sweat...
Yeah, this is what I get for being online when I'm sick. :-) Patience wears thin sometime. Apologies. I feel better after a good night's sleep...
I agree with the rest of the sentiment about improvements which ought to be made. That's the beauty of the living nature of a product like this, in that we can take something and improve upon it.
Granted, the refactor tool is still pretty helpful as it stands, so long as we are aware of limitations inherent in the current implementation. I have nothing but respect for those who worked hard to create this tool in the first place. I use it all the time and haven't had any problems (granted, I'm usually only renaming my own methods and variables, not inherited methods.
And I do think that discussion of the shortcomings, preferred operation, preferences, and so on are nothing but beneficial (even when unfortunately tinged with pointy and prickly language :-P ) and can help guide the way these things are implemented and improved in the future.
+1 on the position that the API should be immune.
+1 on limiting to the active project scopeAnyway, just my (more levelheaded) thoughts this morning... carry on.
-
Also, another thought I have on this - it would be nice to be able to do context aware refactoring. What I mean by that is:
@class BaseClass ...
class MyClass : public BaseClass ...@
If I click refactor on the first BaseClass identifier it is logical to assume I want to refactor the name of this class in the entire (project) hierarchy.
BUT if I click refactor on BaseClass in the context of a class I am inheriting from, it would be nice to refactor it in that context and change the class name of the class that MyClass inherits from... in the declaration, definition, constructor and potential calls to base class methods in the body of MyClass. Makes sense, doesn't it?
-
Please file bug reports about the features you want! Stuff reported here will be lost.
-
I've been considering a feature suggestion. The current refactoring mechanism is literally blind, dumb and deaf, and that is OK in most of the cases, not to mention many experience developers are used to such behavior. So I don't see a reason for this to change.
But I also don't see a reason not to introduce an additional "smart refactor" tool that distinguishes between API/library and project scope, respects the context of the refactored item and offers the option to keep it to current class or reach all the way down into virtual hierarchies in the project or if needed all the way into the API.
-
I just got bitten by this one in a big way...had to reinstall in order to fix all the broken headers...