Re: [jdt-ui-dev] UseSupertypeWherePossible released

["Adam Kiezun" <Adam_Kiezun@xxxxxxx>]

> Yes, but I was thinking of posting the "unnecessary import" data to the
> developer list.  Since this is so easy to detect and remove in Eclipse,
> there should really have been 0!

<g>

> Have you considered "mass" refactorings for this--sort-of like a
> "organize imports" at the project level?

in latest 2.1 builds

> Agreed, I'll have to look at how you approach this -- because I want to
> assure absence of "overspecific variables" the "step-by-step" approach
> seemed logical.  After the first change our (yet to be finished), 
> incremental analysis (today you sadly rerun it all) would update its
> state based upon the change and make further "suggestions".

cool.
would the database be updated on build or save?

> (1) Can you send me a code pointer on your refactoring.  I downloaded a
> nightly build and couldn't find it?  I also couldn't find it in the UI. 
> I probably got the wrong "stream", do I need to get it from CVS?

nope, it's in there - select a type and right click
or use the global refactor menu.
(like i said - the code needs cleanup. a major cleanup actually)
aha - the class is called UseSupertypeWherePossibleRefactoring

> (2) Is there any interest in enhancing the "Tasks" view to allow richer
> explanation of "why" a task is on the list (sort-of like our "Code
> Quality Advice" rationale, but probably not exactly) -- this would be a
> big help for assurance type tools within Eclipse and I think would be a
> nice incremental improvement on the current "filter" the table approach
> when dealing with huge numbers of tasks (via flexible categorization).
> My team at CMU would be interested in contributing on this effort, but
> has been leery of changing "built-in" components to avoid "code-fork"
> issues.

honestly, i prefer a separate view - i never use the task list (plus, it's a list an you might want to have a tree)
> 
> The worst was "// should not happen" (in TextViewer.java) and other
> similar non-absolute comments that probably make sense in context.  I
> didn't note any TBDs or such -- we were surprised by the ignored
> exception results being so high (I expected far fewer cases) and are
> starting to investigate beyond the "default-try-ignore" pattern we noted
> as quite common in the paper.  The empirical data in this case suggest a
> possible mismatch between common Java practice and current "rules of
> thumb." We are suffering, somewhat, by the lack of a good AST pattern
> detector--does one exist within your refactoring infrastructure we
> should have a look at?

nope, we have no complex ast matching (let alone pattern detection) infra - just isomorphism matching + name resolving.
so far we never needed one.
Don Roberts et al. had something but it was for smalltalk and that's a totally different world.

a.