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.
