[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] Refactorings
|
we will check whether the publishing agreement allows us to make
it available on our component page on the Web.
If not we will send you a copy.
--erich
"Jens Lukowski"
<jens.lukowski@gmx To: <jdt-ui-dev@xxxxxxxxxxx>
.de> cc:
Sent by: Subject: Re: [jdt-ui-dev] Refactorings
jdt-ui-dev-admin@e
clipse.org
11/19/2001 09:55
PM
Please respond to
jdt-ui-dev
it seems like ACM hasn't got the current proceedings online yet
could you please send me a copy ?
greetings
Jens Lukowski
----- Original Message -----
From: "Erich Gamma/ZRH/OTI" <Erich_Gamma@xxxxxxx>
To: <jdt-ui-dev@xxxxxxxxxxx>
Cc: <jdt-ui-dev@xxxxxxxxxxx>
Sent: Friday, November 16, 2001 12:16 PM
Subject: Re: [jdt-ui-dev] Refactorings
>
> We have a short paper that appeared in the OOPSLA addendum of this year.
> It describes the overall refactoring approach. Do you have access to this
> addendum?
>
>
>
>
> "Dirk
> Baeumer/ZRH/OTI" To:
jdt-ui-dev@xxxxxxxxxxx
> <Dirk_Baeumer@oti. cc:
> com> Subject: Re:
[jdt-ui-dev] Refactorings
> Sent by:
> jdt-ui-dev-admin@e
> clipse.org
>
>
> 16.11.2001 11:01
> Please respond to
> jdt-ui-dev
>
>
>
>
>
>
> Hi Jens,
>
> unfortunatelly the conversion of SEF to the new text change
infrastructure
> has already been done.
> What IMO would be a good starting point to get familiar with the current
> refactoring infrastrucuture
> is to extend the SEF refactoring. It has currently the following
> limitations:
>
> - doesn,'t work for base types. The reason is, that you have to do a
deeper
> analysis of the write access
> statements since base types allow prefix and postfix operators.
Consider
> the following example:
>
> int x;
> int i= x= field++;
> This can't be easily transformed using a setter method (see also
> SelfEncapsulateFieldRefactoring.checkActivation()).
>
> - doesn't support write access which are used in another expression. For
> example int x= field= y; In this
> case the setter method has to return the assigned value (see also
> AccessAnalyzer.checkParent()).
>
> Jens what do you think about extending SEF to handle those cases
correctly.
> You could come up with a small proposal
> how to fix these cases. This gives you an easy appreciation to
refactoring
> without having the need to understand the
> whole AST, Refactoring UI, and change infrastructure.
>
> Dirk
>
>
>
>
> "Jens Lukowski"
> <jens.lukowski@xxxxxx> To: "Jdt-Ui-Dev@Eclipse.
> Sent by: Org" <jdt-ui-dev@xxxxxxxxxxx>
> jdt-ui-dev-admin@xxxxxxxxxxx cc:
> Subject: [jdt-ui-dev]
> Refactorings
> 15.11.2001 20:50
> Please respond to jdt-ui-dev
>
>
>
>
>
>
> Hi
>
> I would like to implement some refactorings.
> I have taken a look at the SelfEncapsulateField(SEF) refactoring.
> Is the migration to the new text change infrastructure already done
> for this refactoring ?
> if so, I would like to start with some new ones.
> I have the book by Martin Fowler.
> Is there any refactoring which is preferred ???
> what about the try/catch selection block code generation ?
>
> and what about things like connectors/ports from
> the architecture systems ? (I implemented them once
> as part of my study in a similar system like the "compiler" used here
> which was developed by compiler builders for integrating things
> like AOP, architecture systems, refactorings and so on, all as a
> precompiler...)
>
> greetings
> Jens Lukowski
>
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
>
>
>
>
>
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
>
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
