AW: [jdt-ui-dev] Re: OOPSLA *2001* "Implementing Refactoring Support..."

["Valentino Kyriakides" <vkyriakides@xxxxxx>]

Hello Adam,

>
> we are willing to provide some better documentation of the refactoring
> support internals.

that would be fine and I believe many people will welcome and honor this.

Well you know, every complex framework or API also lives and dies with it's
documentation. So even the finest concepts and architectures are mostly
useless for third party users/developers, if you don't provide them some
docus/examples which show and guide them through the materia. - I mean here
especially, that mostly nobody is willing to reengineer the complex
internals of any undocumented APIs or the like, since that's a boring and
badly time consuming task, most people don't have. Beside this, it's always
difficult to follow foreign code for different reasons, I wouldn't go into
detail here and yet. - So the best is always if the initial developers of
some architecture would also keep in sync some docus for the users of their
architectures.

Let's take here the analogy of Erich Gammas paper titled "why programmers
like to write tests...", which should stand also to some degree for writing
docus too (even I know and agree that this can be sometimes a boring task
for coders...).

However, I hope that the Eclipse refactoring architecture will move into the
direction towards an full blown reusable refactoring API, even the usual
time pressure might not usually allow todo so.


> for now, here's some more detailed overview:
>
> when a refactoring action is selected, the refactoring object is created
> a method checkActivation is called to see if the refactoring can be
> activated on the currect selection
> then, if all is fine, the action shows up in the menu
>
> if  the user select s the menu item the action is run (by calling
> the 'run'
> method)
> the refactoring wizard comes up to collect infrormation from the
> user (like
> the new for a class)
> checkInput is then called to check the remaining preconditions
> if that fails, the ErrorWizardPage is shown
> if it succeeds,
> method createChange is called and the PreviewWizardPage comes up (the one
> that shows the diff between the current state and the refactored state)
>
> the user pressed finish, and the change is performed
> (IChnage.perform(...))
>
> hope that helps a bit
> a.
>

Thank's, I will go through the whole steps (from inside of the IDE and from
the code sources ) for one concrete refactoring, maybe SEF as you suggested,
in order to catch up the overall flow and involved classes for the
refactoring.

If I encounter problems or get lost in the involved and used package/class
hierarchy, I will ask again for help or explanations.


Again, thank you for your help, greetings

-Valentino