Home » Modeling » TMF (Xtext) » Refactoring nested elements/references
| Refactoring nested elements/references [message #892381] |
Wed, 27 June 2012 19:21  |
Eclipse User |
|
|
|
Hi,
I feel like I have been chasing my tail for a while now and hope to get some
pointers here...
I have refactor/rename working nicely for the most part. However, I have
this scenario which I haven't managed to figure out yet:
Consider a case similar to Java/C++ method -- a method contains a list of
statements (expressions). In the case of a recursive method, a statement
within that method references the method. The source URI fragment for the
statement that makes the recursive call contains the method name in it. When
the method is renamed, the following happens:
1. Find the target element (method). Check.
2. Find all references (statement containing reference to method). Check.
3. Rename declaration (method renamed). Check.
3. Update references - Failed! The reason being that the referring
element/statement can no longer be found because the method has already been
renamed.
Am I missing something obvious here? I shouldn't need to put all the
statements within the method into the "dependents" list, should I?
Thanks!
Mary
|
|
| | |
| Re: Refactoring nested elements/references [message #892780 is a reply to message #892481] |
Fri, 29 June 2012 11:49  |
| Eclipse User |
|
|
|
Maybe I'm missing something... let me try to explain my case again..
So, in the RenamedElementTracker, I do see...
- renamed element (say, MethodA) and the URI (say, /fragment/path/MethodA)
- find references to target element (say, a statement within Method that
makes a recursive call to MethodA)
note that the source URI for the statement is
/fragment/path/MethodA/statement.0
- apply declaration refactoring
- recalculate the URI for the renamed element (say, new URI for the method
is /fragment/path/MethodB)
- update references -- this fails because in order to update the reference,
it first tries to find the reference (the statement within the method). But
that fails because the source URI for the statement contains the old method
name -- /fragment/path/MethodA/statement.0
"Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
news:jshhg1$ki4$1@xxxxxxxxe.org...
> This is exactly the purpose of the
> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>
> -Sample a list of renamed elements and their URIs
> -Apply the declaration refactoring
> -recalculate the URIs for the renamed elements
>
> The resulting URI to URI map is used in the IReferenceUpdater.
>
>
>
> Am 28.06.12 01:21, schrieb Mary Komor:
>> Hi,
>>
>> I feel like I have been chasing my tail for a while now and hope to get
>> some pointers here...
>>
>> I have refactor/rename working nicely for the most part. However, I have
>> this scenario which I haven't managed to figure out yet:
>>
>> Consider a case similar to Java/C++ method -- a method contains a list
>> of statements (expressions). In the case of a recursive method, a
>> statement within that method references the method. The source URI
>> fragment for the statement that makes the recursive call contains the
>> method name in it. When the method is renamed, the following happens:
>>
>> 1. Find the target element (method). Check.
>> 2. Find all references (statement containing reference to method). Check.
>> 3. Rename declaration (method renamed). Check.
>> 3. Update references - Failed! The reason being that the referring
>> element/statement can no longer be found because the method has already
>> been renamed.
>>
>> Am I missing something obvious here? I shouldn't need to put all the
>> statements within the method into the "dependents" list, should I?
>>
>> Thanks!
>>
>> Mary
>
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
|
|
|
| Re: Refactoring nested elements/references [message #892944 is a reply to message #892780] |
Mon, 02 July 2012 02:01 |
| Eclipse User |
|
|
|
That's because you implemented the IRenameElemenStrategy wrong:
You have to modify the semantic element directly, like calling setName()
on it. The tracker keeps a ref to this element when renaming it. It's
the only chance it has to find it again. If that's not possible in your
case, you have to implement your own tracker, or fix the rename strategy.
Am 29.06.12 17:49, schrieb Mary Komor:
> Maybe I'm missing something... let me try to explain my case again..
>
> So, in the RenamedElementTracker, I do see...
>
> - renamed element (say, MethodA) and the URI (say, /fragment/path/MethodA)
>
> - find references to target element (say, a statement within Method that
> makes a recursive call to MethodA)
> note that the source URI for the statement is
> /fragment/path/MethodA/statement.0
>
> - apply declaration refactoring
>
> - recalculate the URI for the renamed element (say, new URI for the
> method is /fragment/path/MethodB)
>
> - update references -- this fails because in order to update the
> reference, it first tries to find the reference (the statement within
> the method). But that fails because the source URI for the statement
> contains the old method name -- /fragment/path/MethodA/statement.0
>
>
>
> "Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
> news:jshhg1$ki4$1@xxxxxxxxe.org...
>> This is exactly the purpose of the
>> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>>
>> -Sample a list of renamed elements and their URIs
>> -Apply the declaration refactoring
>> -recalculate the URIs for the renamed elements
>>
>> The resulting URI to URI map is used in the IReferenceUpdater.
>>
>>
>>
>> Am 28.06.12 01:21, schrieb Mary Komor:
>>> Hi,
>>>
>>> I feel like I have been chasing my tail for a while now and hope to get
>>> some pointers here...
>>>
>>> I have refactor/rename working nicely for the most part. However, I have
>>> this scenario which I haven't managed to figure out yet:
>>>
>>> Consider a case similar to Java/C++ method -- a method contains a list
>>> of statements (expressions). In the case of a recursive method, a
>>> statement within that method references the method. The source URI
>>> fragment for the statement that makes the recursive call contains the
>>> method name in it. When the method is renamed, the following happens:
>>>
>>> 1. Find the target element (method). Check.
>>> 2. Find all references (statement containing reference to method).
>>> Check.
>>> 3. Rename declaration (method renamed). Check.
>>> 3. Update references - Failed! The reason being that the referring
>>> element/statement can no longer be found because the method has already
>>> been renamed.
>>>
>>> Am I missing something obvious here? I shouldn't need to put all the
>>> statements within the method into the "dependents" list, should I?
>>>
>>> Thanks!
>>>
>>> Mary
>>
>>
>> --
>> Need professional support for Eclipse Modeling?
>> Go visit: http://xtext.itemis.com
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Refactoring nested elements/references [message #898638 is a reply to message #892944] |
Thu, 26 July 2012 20:09 |
| Eclipse User |
|
|
|
The problem was with my customization to the IDependentElementsCalculator --
I was not calculating all the dependents correctly. I have now fixed the
problem and it is working well. Thanks!
Mary
"Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
news:jsrdf8$r3$1@xxxxxxxxe.org...
> That's because you implemented the IRenameElemenStrategy wrong:
> You have to modify the semantic element directly, like calling setName()
> on it. The tracker keeps a ref to this element when renaming it. It's the
> only chance it has to find it again. If that's not possible in your case,
> you have to implement your own tracker, or fix the rename strategy.
>
> Am 29.06.12 17:49, schrieb Mary Komor:
>> Maybe I'm missing something... let me try to explain my case again..
>>
>> So, in the RenamedElementTracker, I do see...
>>
>> - renamed element (say, MethodA) and the URI (say,
>> /fragment/path/MethodA)
>>
>> - find references to target element (say, a statement within Method that
>> makes a recursive call to MethodA)
>> note that the source URI for the statement is
>> /fragment/path/MethodA/statement.0
>>
>> - apply declaration refactoring
>>
>> - recalculate the URI for the renamed element (say, new URI for the
>> method is /fragment/path/MethodB)
>>
>> - update references -- this fails because in order to update the
>> reference, it first tries to find the reference (the statement within
>> the method). But that fails because the source URI for the statement
>> contains the old method name -- /fragment/path/MethodA/statement.0
>>
>>
>>
>> "Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
>> news:jshhg1$ki4$1@xxxxxxxxe.org...
>>> This is exactly the purpose of the
>>> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>>>
>>> -Sample a list of renamed elements and their URIs
>>> -Apply the declaration refactoring
>>> -recalculate the URIs for the renamed elements
>>>
>>> The resulting URI to URI map is used in the IReferenceUpdater.
>>>
>>>
>>>
>>> Am 28.06.12 01:21, schrieb Mary Komor:
>>>> Hi,
>>>>
>>>> I feel like I have been chasing my tail for a while now and hope to get
>>>> some pointers here...
>>>>
>>>> I have refactor/rename working nicely for the most part. However, I
>>>> have
>>>> this scenario which I haven't managed to figure out yet:
>>>>
>>>> Consider a case similar to Java/C++ method -- a method contains a list
>>>> of statements (expressions). In the case of a recursive method, a
>>>> statement within that method references the method. The source URI
>>>> fragment for the statement that makes the recursive call contains the
>>>> method name in it. When the method is renamed, the following happens:
>>>>
>>>> 1. Find the target element (method). Check.
>>>> 2. Find all references (statement containing reference to method).
>>>> Check.
>>>> 3. Rename declaration (method renamed). Check.
>>>> 3. Update references - Failed! The reason being that the referring
>>>> element/statement can no longer be found because the method has already
>>>> been renamed.
>>>>
>>>> Am I missing something obvious here? I shouldn't need to put all the
>>>> statements within the method into the "dependents" list, should I?
>>>>
>>>> Thanks!
>>>>
>>>> Mary
>>>
>>>
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>
>
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
|
|
|
Goto Forum:
Current Time: Wed Jul 23 12:23:40 EDT 2025
Powered by FUDForum. Page generated in 0.25761 seconds |
Home