Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Xbase refactoring for static methods
Xbase refactoring for static methods [message #1563820] Wed, 14 January 2015 12:23 Go to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Hi

in my Xbase DSL I can define functions that are then inferred into
static methods of a Java class (I don't even need access to definitions
in other files, I don't have an import section, and there are no other
special features in this DSL). The name of the generated Java class is
computed using the file name (similar to the Scripting example of 7
languages):

val className =
"mypackage."+script.eResource.URI.trimFileExtension.lastSegment

Refactoring works correctly but if I refactor a function name, at the
end of the refactoring all references to that function are replaced with
the fully qualified name.

For example,

MyFile.mydsl

op foo() {
return foo();
}

becomes after refactoring

op foo() {
return mypackage.MyFile.foo();
}

which is fine, but ugly to look at ;)

what should I customize to avoid this?

I debugged a little, and I noted that

DefaultReferenceUpdater class

protected void createReferenceUpdate(IReferenceDescription
referenceDescription, URI referringResourceURI,
ElementRenameArguments elementRenameArguments, ResourceSet resourceSet,
IRefactoringUpdateAcceptor updateAcceptor) {
URI referringElementNewURI = elementRenameArguments
.getNewElementURI(referenceDescription.getSourceEObjectUri());
EObject referringElement =
resourceSet.getEObject(referringElementNewURI, false);
URI targetElementNewURI =
elementRenameArguments.getNewElementURI(referenceDescription.getTargetEObjectUri());
EObject newTargetElement = resourceSet.getEObject(targetElementNewURI,
false);
createReferenceUpdate(referringElement, referringResourceURI,
referenceDescription.getEReference(),
referenceDescription.getIndexInList(), newTargetElement,
updateAcceptor);
}

newTargetElement is already fully qualified...

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: Xbase refactoring for static methods [message #1565298 is a reply to message #1563820] Thu, 15 January 2015 07:39 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Lorenzo,

you may want to dig into
SerializerScopeProvider.getExecutableScope(XAbstractFeatureCall,
JvmIdentifiableElement) and see what's going wrong there.

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Xbase refactoring for static methods [message #1565587 is a reply to message #1565298] Thu, 15 January 2015 11:12 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/01/2015 08:39, Sebastian Zarnekow wrote:
> Hi Lorenzo,
>
> you may want to dig into
> SerializerScopeProvider.getExecutableScope(XAbstractFeatureCall,
> JvmIdentifiableElement) and see what's going wrong there.

Hi Sebastian

thank you for the hint; I tried to debug that part, and everything seems
to work correctly (or at least, it looks like it behaves the same as
Xtend does for refactoring of static methods). Note that while
refactoring is triggered, and I type the new name, all references are
being updated correctly (i.e., not fully qualified) while I'm typing,
i.e., lively. The problem takes place when I press ENTER: the
references are then textually updated with the fully qualified name...

So the problem takes place somewhere else; during the debugging I can't
seem to find the exact place where the wrong behavior takes place... I
tried to debug until the refactoring unit of work terminates...

I also tried to add a custom QualifiedNameProvider so that

MyFile.mydsl
------------
op foo() {
return foo();
}

the qualified name of foo() corresponds to the qualified name of the
inferred operation, mypackage.MyFile.foo, but this does not solve the
problem either...

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: Xbase refactoring for static methods [message #1565640 is a reply to message #1565587] Thu, 15 January 2015 11:54 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Lorenzo,

I take the scope that is produced by #getExecutableScope returns an
EObjectDescription for the method with the right name, e.g. the short
version?

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Xbase refactoring for static methods [message #1565672 is a reply to message #1565640] Thu, 15 January 2015 12:11 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/01/2015 12:54, Sebastian Zarnekow wrote:
> Hi Lorenzo,
>
> I take the scope that is produced by #getExecutableScope returns an
> EObjectDescription for the method with the right name, e.g. the short
> version?

Exactly: the EObjectDescription has the short name...

another funny symptom: as I said when I type in the editor references
are correctly updated (with the short name); if I do NOT press ENTER the
document stays modified correctly (short name); if I press ENTER the
document text is updated wrongly (fully qualified name). If instead of
ENTER, I open the rename dialog, the preview of the change shows the
final result with the wrong text (fully qualified name).

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: Xbase refactoring for static methods [message #1565681 is a reply to message #1565672] Thu, 15 January 2015 12:19 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
OK, some updates: I can reproduce exactly the same problem with Xtend
(2.7.3) :(

package mypackage

class MyXtendFile {
def static void foo() {
foo()
}
}

start renaming foo to bar and then press ENTER, the resulting source
file is:

package mypackage

class MyXtendFile {
def static void bar() {
mypackage.MyXtendFile.bar()
}
}

I'm sorry I did not detect this before, but while debugging the focus on
the editor is lost and thus I did not try to press ENTER.

should I file a bug?

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: Xbase refactoring for static methods [message #1565906 is a reply to message #1565681] Thu, 15 January 2015 15:03 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
The linked editing is just some search&replace trick. The actual
refactoring happens after <enter>.

Could you please file a ticket for this issue? Thanks!

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Xbase refactoring for static methods [message #1565978 is a reply to message #1565906] Thu, 15 January 2015 15:53 Go to previous message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/01/2015 16:03, Sebastian Zarnekow wrote:
> The linked editing is just some search&replace trick. The actual
> refactoring happens after <enter>.
>
> Could you please file a ticket for this issue? Thanks!
>
> Best,
> Sebastian

Done, https://bugs.eclipse.org/bugs/show_bug.cgi?id=457617
I also added some additional findings (but I have no idea if they can
help :)

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Previous Topic:"Mark Occurrences" in EmbeddedXtextEditor
Next Topic:Parser for Column Based Programming Language
Goto Forum:
  


Current Time: Fri Apr 26 15:27:56 GMT 2024

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

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

Back to the top