10.1. Creating Delete Refactorings

The Delete refactoring is available via "System""New Delete Refactoring..." or in the context menu when selecting an appropriate element.

A delete refactoring may be applied to the following (physical) elements (i.e. elements that come from the parsing process and are displayed in the Navigation view):

  • Non-external programming elements (e.g. types, methods, fields)

  • Non-external Directories (but not root directories)

  • Non-external Namespaces

  • Dependencies (parser level or aggregated)

When deleting parser level or aggregated dependencies there are up to 3 options. Their appearance, order and selected default option depend on the current context:

  • Delete Parser Dependencies: Delete the currently contained parser dependencies of a given edge based on parser dependency patterns.

  • Delete Parser Dependencies Based on Endpoints: Delete the parser dependencies of a given edge based on end point patterns, after the next 'refresh' there could be more or less matches.

  • Delete Violating Parser Dependencies: Only delete the violating parser dependencies of a given edge based on parser dependency patterns.

Directories are always deleted recursively. Namespaces can be deleted flat or recursively. When deleting a type all its methods and fields or nested types are deleted.

Delete refactorings on (physical) namespaces may also be applied in the (logical) Namespaces view. Since a logical namespace (either in system or module scope) may be based on more than one physical namespace, the deletion of a logical namespace might delete several physical namespaces.

Delete refactorings may also be applied in the Architecture view.

Delete refactorings may also be applied in the Exploration, Graph and Dependencies View which are opened based on arbitrary Navigation, Namespace and Architecture view selections.

Delete refactorings can be managed in the Refactorings view as described in Section 10.3, “ Managing Refactorings ”.