[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [jdt-ui-dev] Participating in Refactorings proposal
|
Hi Valentino,
I added your comments and my answers to the bug report 37937.
Unfortunatelly
I wasn't able to add you to the bug's CC list. You don't have a bugzilla
account.
Dirk
"Valentino
Kyriakides"
<vkyriakides@web. To
de> <jdt-ui-dev@xxxxxxxxxxx>
Sent by: cc
jdt-ui-dev-admin@
eclipse.org Subject
RE: [jdt-ui-dev] Participating in
Refactorings proposal
07/28/2003 07:52
PM
Please respond to
jdt-ui-dev@eclips
e.org
Hi Dirk,
I've just took a first rough view on the proposal and thus will some day
later respond to that in more detail.
However, a first quick thought for an addition would be a possibility to
exclude/hide specific marked/signed java sources (compilation units) from
refactorings at all. This would be an important issue for automatically
generated java compilation units via generators and the like.
1) A sketched scenario:
Say you usually would have some sort of none java source model (file) as
input for a generator, which in turn then creates/generates the
corresponding java compilation units according to the settings inside the
none java input sources. Now the problem is, that you might want to perform
custom refactorings (via processors/participants) on the generator source
models (the generator input files), but prevent refactorings to also
work/touch the generator created java output sources. AFAI can see, there
is
no direct reusable capability inside Eclipse to allow just the compilation
of java compilation units, but prevent the refactoring for certain selected
java compilation units (?). During our tryouts by marking generator based
java output as read only or using Eclipse filters etc. we were not able to
address these refactoring related issues.
2.) I don't know if the proposal already addresses this (?), but the
refactoring participants should also be generic enough to be usable in a
two
way manner, e.g. by first selecting/performing a foreign source model
refactoring and afterwards performing any possible needed related java
restructurings. What I mean is, instead of "JAVA -then-> NONE JAVA"
refactoring flow it might be sometimes also desirable to perform the
opposite direction "NONE JAVA -then-> JAVA" refactoring flow. - Even I
think
that technically, hidden under the hood and for end users in a suggestive
manner, "NONE JAVA -then-> JAVA" can also be performed just via the
"JAVA -then-> NONE JAVA" way. However, it might be generally interesting to
see how to address such two-way direction refactorings...
Greetings Valentino
> -----Original Message-----
> From: jdt-ui-dev-admin@xxxxxxxxxxx
> [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]On Behalf Of Dirk Baeumer
> Sent: Monday, July 28, 2003 3:17 PM
> To: jdt-ui-dev@xxxxxxxxxxx; platform-ui-dev@xxxxxxxxxxx;
> platform-core-dev@xxxxxxxxxxx
> Subject: [jdt-ui-dev] Participating in Refactorings proposal
>
>
> We've just posted a first revision of the "Participating in Refactorings"
> proposal which is part of the plan item (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37937).
>
> Please see
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-hom
> e/r3_0/proposals/refactoring/participants.html
>
>
> Comments are critiques are most welcome. Please add to bug 37937.
>
>
> Dirk
>
> _______________________________________________
> 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
