On Sun, 26 Aug 2012 00:33:01 +0200 "Mehrdad" <[email protected]> wrote:
> On Saturday, 25 August 2012 at 22:11:12 UTC, Araq wrote: > > Because of reflection, refactoring can't do an accurate job in > > Java/C# either. > > > Uh, you're being VERY unfair here. > > C# and Java refactoring tools are 100% accurate for compile-time > code. > > Calling them "inaccurate" because of reflection is completely > missing the point. > > C++ or D tools can't even do their compile-time job to begin > with, even forgetting about RTTI. No, I think Araq raises a good point here: Reflection screws with automated refactoring, period, and Java and D both have reflection. Whether that reflection is runtime or compile-time doesn't change anything here. Java code that uses reflection can't be perfectly auto-refactored. D code that uses reflection can't be perfectly auto-refactored. Same effect either way. Saying that it counts for compile-time but not for run-time is just arbitrarily moving the goal-posts. Of course, D also has other things besides reflection that can mess with refactorings, like mixins+ctfe, but hey, anyone can still stick a code-generator in front of a call to "javac", and you've got the same problem (only clunkier to use and even *less* likely to be refactorable). Not saying that's as common in Java as mixins+ctfe are in D, but the point is: it's features/techniques that mess with auto-refactoring, not languages. It *is* a tradeoff, admittedly. But I'm not sure how fair it is to blame a language for it rather than a technique. And I think that many people, even if not *all* (can't please all the people all the time), would find the tradeoff to be a net gain. I certainly do, at least.
