Automatic code refactoring

Ingo Oeser ioe-news at rameria.de
Sat Aug 4 07:02:01 PDT 2007


Robert Fraser wrote:

> This is probably jumping way ahead of myself here, but if (some day, in
> the far future), Descent were to gain some automated D code refactoring
> support, what would you like to see?
> 
> So far I've thought of/stolen from the JDT:
> ----------
> - Renaming/moving a module (references to it will be updated)

Yes. Without any question, since this this just file movement at the 
moment :-)

+ Make all imports of module private.
+ Make all imports of all modules private.
+ Make all imports of a module static and fix up users.
 
> - Changing a function or template signature (and updating
> references/inserting default values where appropriate)
> 
> - Renaming a variable/function/template/etc and updating references.

Highly desired. Please have a possibility to ask the user per case or not.
The implementation is also very simple, if you use the D compiler frontend
already.

Rationale: Sometimes you rename sth. to forcibly find all its users, 
        when you have to break the semantic of sth. (e.g. badly designed, 
        non extensible core interfaces) in a big project.
        Supporting this kind of workflow would be great.

 
> - Inline a function (either a single invocation of it or everywhere it's
> used).

Let the compiler do that. Always! Everything else just asks for long
function bodies, if junior programmers try to "optimise" code.

> - Expand a mixin/compile-time function/etc. to its actual value/code
> (again, either in a single place or everywhere).

Very useful for readability! Undo would be important here :-)
 
> - Struct-to-class or class-to-struct (possibly, I'm not sure how hard this
> would be to automate. The class-to-struct one, esp. if structs get
> constructors, seems like it'd be a lot easier if no inheritance is used).

Maybe more useful and easier to implement would be:
+ Extract class members to private struct, build accessors to it
  into class and fix up all users.

Struct to class might be nearly impossible, because structs have properties,
which classes don't have (e.g. defined member order, can be stored and
retrieved, can be shared with C/C++ etc.).

> - Automatically import modules for symbols if the symbols can be resolved
> somewhere in the project or attached libraries (and choose from a list if
> there are multiple possibilities). This will remove the need to manually
> import stuff. Either the entire module or a selective import can be used.

Very useful! But please do a private import, to not break interfaces this
way. I guess not making private imports the default are a language design 
oversight, since I see really no reason for this.

> Anyone have any other ideas or things they'd like to see?

<joke>
Adding "synchronized" where it would be required.
</joke>

Best regards

Ingo Oeser



More information about the Digitalmars-d mailing list