Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Refactoring nested elements/references
Refactoring nested elements/references [message #892381] Wed, 27 June 2012 23:21 Go to next message
Mary Komor is currently offline Mary KomorFriend
Messages: 48
Registered: July 2009
Member
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 #892448 is a reply to message #892381] Thu, 28 June 2012 09:00 Go to previous messageGo to next message
Holger Schill is currently offline Holger SchillFriend
Messages: 71
Registered: July 2009
Member
Did you implement the refactoring on your own? Refactoring support is
already there in Xtext 2.x and above to address excatly this problem via
LTK.

Please have a look at the RenameRefactoringFragment in you mwe2 file.

Cheers,

Holger


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 #892481 is a reply to message #892381] Thu, 28 June 2012 12:08 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 658
Registered: July 2009
Senior Member
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 #892780 is a reply to message #892481] Fri, 29 June 2012 15:49 Go to previous messageGo to next message
Mary Komor is currently offline Mary KomorFriend
Messages: 48
Registered: July 2009
Member
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 06:01 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 658
Registered: July 2009
Senior Member
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] Fri, 27 July 2012 00:09 Go to previous message
Mary Komor is currently offline Mary KomorFriend
Messages: 48
Registered: July 2009
Member
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
Previous Topic:NoClassDefFoundError for org/slf4j/LoggerFactory upon Xtext generation
Next Topic:Escaping keywords with a QualifiedNameValueConverter?
Goto Forum:
  


Current Time: Fri Dec 19 08:12:03 GMT 2014

Powered by FUDForum. Page generated in 0.03056 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software