D-etractions A real world programmers view on D

[Chris Cain]

On Saturday, 25 August 2012 at 13:03:13 UTC, Peter Alexander 
wrote:
> You would have to expand the template (which involved CTFE) and 
> then somehow infer that the name of the variable came from that 
> string in the template args.
> ...
> but to do automated refactoring you need simple semantic 
> analysis, and this is something that D does not have.

I agree. However, I'd even go as far as to say it's _definitely_ 
impossible (at least, in general).

Consider a mixin that makes a string like this:

template awesomeVar(string param) {
     enum awesomeVar = "int awesomeVariableOf" ~ param ~";";
}

and it's used in some classes:

class A {
    ...
    mixin(awesomeVar!"Doom");
    ...
}

class B {
    ...
    mixin(awesomeVar!"Epicness");
    ...
}

Later in code you see:
    A a = new A;
    ...
    a.awesomeVariableOfDoom = 7;
    ...

You can decide to change that to "awesomeVariableOfStuff" and 
sufficiently smart refactoring software could figure out that it 
just needs to change A's mixin declaration to 
mixin(awesomeVar!"Stuff") ... I make it sound like "sufficiently 
smart refactoring software" would be easy to write, but it 
wouldn't be.

Or you decide, "Oh, I'm going to refactor that and change the 
name to 'incredibleVariableOfDoom'". So now your refactoring 
software will have to expand the mixin, figure out the relevant 
parts of the mixin to modify, figure out every class that uses 
the mixin (such as B changing to incredibleVariableOfEpicness), 
and then perform the changes to the relevant parts there as well. 
That sounds much tougher to me.

Now consider if you decide "Oh, I'm going to refactor that and 
change the name to 'iLoveCopyPasta'". In this case, exactly what 
should your software do? Prompt you (maybe) a hundred times to 
resolve the numerous conflicts? Obviously, there's no automated 
way to decide what B's variable should be named. And keep in 
mind, this is a _simple_ mixin.

For all practical purposes, if refactoring will be done on any 
mixins, it will require special casing (for instance, write a 
plugin to refactor bitfields, don't generalize it to work with 
every mixin). That would make it much more reasonable... but it 
makes writing your own mixins less effective (because, 
presumably, you're going to want to write your own plugin to 
handle refactoring your mixin if you're going to use it 
everywhere).


That all said, I still like mixins and it doesn't bother me that 
I'd lose refactoring on certain code. But it's something to be 
aware of, at least.