Automatic code refactoring

Robert Fraser fraserogfthenight at gmail.com
Thu Aug 2 15:26:44 PDT 2007


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)

- Changing a function or template signature (and updating references/inserting default values where appropriate)

- Renaming a variable/function/template/etc and updating references.

- A "use supertype where possible", where references to a particular implementation of an interface or class are updated to use the supertype/interface where possible.

- Extract abstract class, where some (or all, you choose which ones) of the fields/methods of a class are moved to a new abstract class, and the remainder remain as implementations in the subtype.

- Extract interface: create an interface for some or all of the methods of a class.

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

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

- 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).

- 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.
----------

Anyone have any other ideas or things they'd like to see? Descent doesn't even have semantic analysis yet, so this is a mostly theoretical topic, but someday your dreams may become a reality...



More information about the Digitalmars-d mailing list