A while ago Ola Bini offered a theory – refactoring of any kind is a subset of the Halting Problem.
He offers no proof except intuition, but this is interesting, because my intuition suggests this simply isn’t true.
So, here’s my challenge:
Write a java program that does not use reflection or other meta tricks (like making classes on the fly with e.g. javassist) which breaks under an eclipse refactoring script in a non-trivial way.
Alternatively, prove that java is turing incomplete if you ban meta tricks.
I can help you on that last one: You can’t – java without reflection or dynamic class generation is still turing complete, and 99.99% of all tools work withOUT reflection ever being neccessary. Reflection is there for tools like e.g. a debugger, or some sort of generic object viewer. In other words, code tools which make no assumptions about an object or class whatsoever.
Good luck!
(As an aside to the essence of Ola’s post: Even if there are very contrived examples that do break refactoring, how is that relevant? A refactor tool that works under all non-idiotic use of a language is obviously a far sight better compared to Random Texteditor’s replaceAll feature).
{ 4 } Comments
Hi,
Yeah, I know, that’s probably true. My post wasn’t really about the relevant uses of refactoring. I just took issue with blanket statements about 100% of something. So, I grant you that in the everyday case you’re right. There probably is some contrived example that breaks, but that isn’t useful in reality.
Glad that’s sorted. I do think there’s a real discussion here – provided it is held on the proper terms: Including the notion of what tools can do with all that static information.
I’ve dismissed python and rails as fun ideas that aren’t useful, but something like Boo, at least the theory behind it, sounds interesting. It’s very very similar to the intent and purpose of latent typing, yet there’s a convenient ‘out’ for enabling the tools.
There’s also massive inference and typing flexibility such as that expressed by Haskell, which also promises some excellent scalability (in the software development sense). It’s a shame so much of the discussion gets overshadowed by meaningless fodder (like e.g. Bruce Eckel’s post).
I suppose you meant “reflection” instead of “refactoring” in a few places in your post?
nitpickingly yours,
Axel
Axel: Yes, I did. A rather confusing typo indeed. I’ll fix it now.
{ 1 } Trackback
[...] A refactoring changes the shape of your program, while maintaining the program’s behaviour. You do it so the code gets into a shape that makes the changes you are aiming for easier to apply, and makes it easier to reason about their correctness. The correctness of the initial refactoring is guaranteed by your IDE. Note that even a refactoring is a change; it is only guaranteed to be “correct” as long as you live in a closed world, where all the code you might interact with is contained in your IDE project. As soon as you leave that safe haven, using type casts, reflection, dynamic linking, or when you guarantee backwards compatibility for published interfaces, that’s over. [...]