Re: [jdt-ui-dev] Proposal: Refactoring "Remove unused members"

[Mariano Kamp <mkamp@xxxxxx>]

Hi Adam,

  thanks for the checklist. Here is a first throw, which I will refine along 
the way.

  The user should be able to select an arbitrary JavaElement and invoke the 
refactoring on it. I would start with methods only, but increase the scope 
later on to types, packages etc. I believe the only limitation is 
performance. 

  [ Searching the candidates ]
  After selecting a JavaElement a Wizard is fired up where the scope of 
searching for _candidates_ is to be defined. Here comes an outline of some of 
the _visible_ filter criterias to select:

  Selection of Candidate:
  [ includes ]
  access modifiers:
  - public (off)
  - protected (on)
  - package (on)
  - private (on)

  other contained elements:
  - include members of subclasses (on) 
  - etc.  

  by type: 
  - methods (on)
  - anonymous and names inner classes (on)
  - fields (on)
  - etc. (on)
 
  [ excludes ]
  by member names:
  - getters (off)
  - setters (off)
  - regexp method names (off)

  Search for references to candidates:
  - working set etc. (will be inspired by the java search)

  Furthermore the user should be presented with a tip explaining the 
importance to narrow down the search and possibly define a working set, which 
just contains code with the potential to reference the candidates, not also 
third-party-libraries etc. It should also be mentioned what the consequences 
of a to narrow search would be.

  It should also be possible to set _invisible_ excludes on a preference page. 
The defaults will include all methods from Object and the main() method.

  Note: Please bear in mind, that this is only the search for candidates. 
During the search for references to the candidates the excludes and 
deselected includes will obviously not being honored.

  [ Searching the candidates ]
  Here is the beef. See my previous posting (not the accidently sent one 
though ;-).
  When a resource cannot be read (e.g. out of sync) then the search will be 
cancelled and the user will be presented with an error message saying what 
the problem is. The same holds true, if a candidate is read-only.
  The only unanswered question crossing my mind is how to deal with multiple 
errors? Will it make more sense to fail early or to collect all errors (might 
be very slow). I guess it makes sense to make this a preference. I believe 
the multiple-error approach would pay off in the real world. E.g. in my 
current day job project we are forced to use a scm tool utilizing the 
pessimistic approach and so this information is needed for checking out the 
affected ressources.

  [ Displaying the candidates ]
  The candidates, i.e. java elements only referenced by other candidates or 
not referenced at all, should be displayed in a tree view.  Unreferenced java 
elements not referenced by anything in the whole workspace are to be shown on 
the first level. Candidates that will only be unreferenced when another 
candidate will be removed are to be shown below the candidate they depend on. 
The next level will show the candidates depending on candidate depending on a 
top-level candidate etc. etc.

  A depending candidate can be deselected independently of its parent, but can 
only be selected if the parent is also selected. If a parent is deselected 
all children will be deselected too.

  Beneath the candidate will be a check box, triggering the removal.

  extension (from Olivier):
  The checkbox for removal will be replaced by a radio button or list with two 
options: "Remove Element" and "Deprecate Element". Remove Element says it 
all, deprecate element means to change the Java Doc of the element. A 
@deprecated keyword will be added an a TODO marker to be replaced by a good 
explanation why this method has been deprecated and probably what is to be 
used instead.
 
  For this extension it would also be necessary to rethink the tree view. The 
rule would the read as follows: A child is/can only be selected when the 
parent is marked for removal, i.e. a parent marked as deprecated will still 
reference the child. 

  [ Executing the removal / deprecation ]
  That looks pretty straight-forward to me. Of course it has to be checked for 
read-only files (see above), but nothing special I can think of. 

  OK, after the full picture back to the check list:

- how do people invoke the refactoring?
They select a JavaElement and invoke the first wizard page from the context 
menu. The refactoring will be available for all Java Elements. Well, in the 
final implementation. It would be already a worthy refactoring if would just 
work on individual methods.

> - what does the ui look like?
It's golden with red stripes from the upper left to the lower right. There 
will be nice mp3 song playing, downloaded from an illegal server, selected by 
consulting a chart list website and accounting for the current time of the 
day and if is a weekend or not ;-) There will also be a mpeg playing. The 
selection of content will be based on the users age.
Apart from that the first page will ask the user to define the scope of 
candidate selection.

> -- what is the input that the refactoring needs?
a) The raw candidates from the selection and its children and the filter.
b) the Java Elements in the search scope.

> -- is all the input available at once, or do we need to ask additional
> questions after some part of the analysis has been performed?
Well, the filter wizard page does have all input. The display of the removal 
candidates will need the selection of the user how to proceed.

> - what are the possible errors and how to present them to the user?
Unreadable resources. They should be displayed altogether after the search is 
finished. Probably a preference to fail early makes sense here.

> - an application has many 'root' entry points normally (elements that are
> always 'reachable') e.g. the main method is the most obvious one, but every
> test... method is an entry point in a class that subclasses
You should be able to exclude some elements defined by name (regexp) on a 
preference page.
The default settings might also include suite() etc. 

> everything in not-internal packages in eclipse's
> source code is an entry point, etc. We need a way to collect that
> information from the user in an intuitive way.
I am not sure if I got this right ... Is it? We need to care for references 
outside of the workspace, like framework methods not used inside the 
framework or the user code in the workspace?
I don't see a way to compute that. 

Or do you mean to select for example setUp() on some testcase and fear that it 
will be a candidate for removal as it is not referenced in the user code?
That is something the user needs to know about. See the "tip" I want to 
display when defining the search scope. The user needs to know that s/he 
needs to select the junit.jar in the working set. It will be found then in 
the collection process and not removed (see other posting).

On the sunny side the removal is not done automatically. The user needs to opt 
out what elements s/he doesn't want to be removed.

Cheers,
Mariano

On Monday 14 July 2003 13:26, Adam Kiezun wrote:
> Hi Mariano,
> thanks for your detailed description of the problem and suggested solution.
>
> I think that before we start thinking about the implementation, we need to
> focus on the user experience here: - how do people invoke the refactoring?
> (what they select, etc)
> - what does the ui look like?
> -- what is the input that the refactoring needs?
> -- is all the input available at once, or do we need to ask additional
> questions after some part of the analysis has been performed?
> - what are the possible errors and how to present them to the user?
> - an application has many 'root' entry points normally (elements that are
> always 'reachable') e.g. the main method is the most obvious one, but every
> test... method is an entry point in a class that subclasses
> junit.framework.TestCase, everything in not-internal packages in eclipse's
> source code is an entry point, etc. We need a way to collect that
> information from the user in an intuitive way.
>
> a.
> --
> eclipse.org
>
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev