D-etractions A real world programmers view on D

[Nick Sabalausky]

On Sun, 26 Aug 2012 00:33:01 +0200
"Mehrdad" <wfunction at hotmail.com> 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.