Comments on: Delphi’s “refactorings only work in current unit” bug

By: Joe White’s Blog » Blog Archive » Comments on the survey #2: Refactorings

Fri, 22 Feb 2008 13:03:53 +0000

[…] Delphi’s refactorings still don’t work across units if you don’t have every single unit explicitly added to your project file, so a Rename will usually break the build. […]

By: CR

CR — Tue, 03 Jul 2007 15:19:00 +0000

‘using the automated refactoring tool doesn’t introduce anything new to the equation’

Apart from the ‘automated’ (and so, ‘implicitly edited’), sure. But if a unit is so quintessential to a project that it gets edited with it, why ever *not* explicitly add it to that project? By not doing so, doesn’t a person (not yourself though, obviously!) imply it’s more generic than the project (or even project group) at hand, and so shouldn’t be refactored willy-nilly?

Anyhow, to be clear, I’m not disagreeing that the IDE *should* refactor any units used but not explicitly added to the project. I’m just trying to suggest that your closing line - ‘Here’s hoping we get an IDE with refactoring support sometime soon’ - is a bit over the top.

By: Joe White

Joe White — Sun, 01 Jul 2007 20:34:00 +0000

CR: Well, yeah, if you change shared code and don’t recompile all the projects, then you run the risk of breaking the projects you chose not to compile. But the same thing is true if you do the refactoring manually; using the automated refactoring tool doesn’t introduce anything new to the equation.

Now, if you put all of your projects into one project group, and open that project group in the IDE, the refactorings are supposed to work across all of the projects in the group; so if you’re able to put all of your projects into one group, then the refactorings should, theoretically, never break anything at all.

By: Joe White

Joe White — Sun, 01 Jul 2007 20:28:00 +0000

Fernando: good grief, no, it shouldn’t scan your hard drive. I’m not sure where you dreamed that up. It should simply refactor across all the units that are compiled into the project. If the project was compilable before the refactoring, then it had better be compilable after the refactoring — which means the refactoring needs to be able to touch any unit that’s compiled into the project. Right now, it doesn’t; it only follows the unit dependencies one level. That can’t possibly guarantee that the code will stay compilable, because that’s not what the compiler does.

By: CR

CR — Sun, 01 Jul 2007 15:46:00 +0000

Fernando - the point is that if you don’t explicitly add any used library code units to a project, then they will be ignored by the refactoring engine.

That said, while I’d agree this is a bug in its current state (i.e., with no warning as to what the scope of the refactoring engine is), I’m not sure *simply* ‘fixing’ it would be a great move. For if unit X is used by lots of projects, having it changed when refactoring project A will just end up breaking project B, C, etc. So in effect, Fernando’s point rises again, for to be properly comprehensive, the refactoring engine would need to search through the computer looking for any other project effected by changing a given library unit.

By: Fermando Madruga

Fermando Madruga — Sun, 01 Jul 2007 13:55:00 +0000

"The issue is that the refactoring engine only pays attention to the unit you’re currently editing, plus units that have been explicitly added to the project (with Project > Add to Project), or automatically added to the project (by File > New)."

Huh… What else would it do? Search your whole harddrive and connected network drives for unrelated files and make the changes there too?

You make it sound as it’s working as intended and in fact as it *should* work. How else will the engine know when to stop replacing?

Maybe I’m just missing the problem here (and I haven’t looked at the QC report, which I’ll try to do later and maybe then I’ll understand it better)…