10 minutes waiting the rename refactoring finish the work. I went to fetch a cup of coffee, and so far nothing, I have to kill bds.exe.
10 minutes waiting the rename refactoring finish the work. I went to fetch a cup of coffee, and so far nothing, I have to kill bds.exe.
I saw this behavior a few times, I am wondering if is related to Generics types.
I've seen this with regular refactorings as well.
ReplyDeleteThe tooling is just garbage - not even renaming a variable or properly picking up a function return type for declaring a variable or field works sometimes (yes, generics involved)
ReplyDeleteDavid Millington ping
Rest In Peace.
ReplyDeleteI have abandoned using refactorings except for the simplest scenarios. Most of the time it just fails to do anything or throws an error. The refactorings are written in .NET and have received no love for a long time. One more reason to expose a Code DOM and allow third parties to more easily write re-factorings without parsing source files and building their own AST.
ReplyDeleteDidn't we just have this discussion over here https://plus.google.com/u/0/108684844040122144755/posts/Vj5wH8mT9H1
ReplyDeleteplus.google.com - Did you know that the Delphi IDE's rename refactoring (Ctrl+Shift+E) also wor...
All these .Net should be removed from IDE... I'm using MMX...
ReplyDeleteCastalia had better working functionality (not everything in Castalia was good but it was written in Delphi) but when it merged in to the IDE, the [under performing] existing functionality was kept and Castalia's was thrown out...
ReplyDeleteDoes not matter what language it's written in - learn from the best: channel9.msdn.com - Anders Hejlsberg on Modern Compiler Construction
ReplyDeleteModelMaker Code Explorer does the renaming fast and accurately. CNPack (press F2) also does this correctly and fast.
ReplyDeleteEdwin Yip note that MMX refactorings miss the effects in the rest of the project. I've discussed this at length with MMX author Gerrit Beuze years ago, but speed penalty of doing this likely very large and the of work converting MMX to "compile" all potential non-compiling code in the project looks unsustainable with the MMX sales at that time. I don't think sales have improved since then.
ReplyDeleteEdwin Yip cnpack's rename is much dumber than Delphi's. But at least it's always available.
ReplyDeleteDelphi stops trying when it encounters generics, anonymous functions, or even inline type definitions like this range here:
record
Age:0..120;
end;
It was forgivable around the time of Delphi 2005. But this refactoring code was never updated since then, it seems.
Instead, Embarcadero is working on things that i'll never use. Having support for mobile devices and beacons probably sells better than having fixed refactoring or stability improvements. And new features are probably more fun to work on too.
Jeroen Wiert Pluimers It's very sad to see MMX has no significant improvements over the recent years, it's my number one productivity tool.
ReplyDeleteWouter van Nifterick Actually I use the MMX one all the time, I just tried CNPack's local variable renaming... sorry if I wasn't being clear enough.
ReplyDeleteJeroen Wiert Pluimers Re MMX's renaming refactoring affects only the current unit, I'm very OK with that, it's a good balance, if it would rename across the entire project, I don't believe that the performance would be acceptable and *trustable*. Things are almost perfect with the current limit-to-single-unit renaming approach plus GExpert's GREP search function.
ReplyDeleteEdwin Yip your comment shows how low of a bar Delphi developers have when it comes to the capability of their code tooling -.-
ReplyDeleteStefan Glienke +Stefan Glienke Well, actually I have the perfectionism inside of me - although I've learned and realized it's not a good thing life-wise in recent years :) That being said, I'd love to see MMX to have a project-wide renaming feature included. But just my intuition told me that's not very practical given these facts - the difficulty to implement that by a third party company, because EMBT the IDE company itself is at a better position to do such thing - but on the other hand, I don't think EMBT has the intention to do that or to give any help to the MMX companh to do that... thus I had my prevous comment ..
ReplyDeleteEdwin Yip It was not specifically targeted at you personally but more to the "good enough" and "I get it working somehow" attitude just because someone is used to do things in a non ideal way and at some point stops noticing and thus caring.
ReplyDeleteThis goes from language features over tooling around the language and IDE to code people write and how problems are addressed.
I agree that you cannot do the perfect solutions all the time but you should aim for it and go as far as possible.
Delphi's rename refactoring is pretty good - when it works. It renames across multiple units, looks in the right scopes, it renames components both in code and in forms. It even renames associated event handlers.
ReplyDeleteMy guess: somebody at Borland made a decent start and was fired or reassigned when the plug was pulled on Delphi.Net, so it was never finished. It's written in a language that's now even more dead than Delphi itself (J#), and nobody wants to work on that now.
Wouter van Nifterick "It's written in a language that's now even more dead than Delphi itself (J#), and nobody wants to work on that now."
ReplyDeleteI think that is incorrect. They removed the J# dependency 2 versions ago. It was used in some other part of the IDE.
Stefan Glienke I like your attitude, and I wish EMBT and all people making 3rd IDE tools and components would also have such attitude for their products, because that's the only way to success, and that would make a bright future for us Delphi developers, although sometimes we cannot control the situation. But yes, I agree with you that we should still convey such positive info to them (the vendors). PS, Your wonderful TestInsight is an example of showing such attitude, I believe :)
ReplyDeleteLuckily TestInsight is not as invasive as some other plugins (as it does not need to). I have seen experts and design-time packages bring down the IDE numerous times and people many times blamed EMBT/the IDE (not saying that often its the IDE itself though). So extending the IDE is a delicate thing. But that on the other side is the fault of not providing a good enough infrastructure. I mean the ToolsAPI is nice and all but still 90s tech. Look at some other IDEs, like Visual Studio. You can integrate entire new languages into it, including the entire tooling for them.
ReplyDeleteStefan Glienke Yes, another example is Visual Studio Code and the JetBrains products. But unfortunately for us, improving the basics of the IDE is not a high priority in EMBT's todo list.
ReplyDeleteRename refactoring is not easy of course but it's not that hard. In I-Pascal it's working on the whole project replacing all occurrences. Didn't test for big projects but for my project performance is acceptable despite the lack of stub indices yet which will improve performance dramatically.
ReplyDeleteIt's reasonable to use I-Pascal (or OmniPascal) for code editing/analyzing and Delphi for designing forms and debugging.