Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Supporting method overloading
Supporting method overloading [message #1853926] Sun, 24 July 2022 07:10 Go to next message
Mirko Raner is currently offline Mirko RanerFriend
Messages: 120
Registered: July 2009
Location: New York City, NY
Senior Member
I'm working on an Xtext-based language, and until recently I had no need to support overloaded methods (i.e., methods with the same name but a different signature). This has changed now, and I'm a little bit at a loss how I need to change my grammar, scope provider and code generator to accommodate overloaded methods.

The grammar has a named element, MethodDeclaration, and currently this element is referenced in various contexts, for example:
Prefixation returns Expression:
  {Prefixation} operator=[MethodDeclaration|PrefixOperatorSymbol] operand=Prefixation | Invocation;

Invocation returns Expression:
	Primary
	(=>({Navigation.object=current} '.'? member=[MethodDeclaration])
	|=>({Invocation.target=current} arguments=Arguments))*;

BinaryOperation: left=Expression operator=[MethodDeclaration] right=Expression;

NamedArgument: key=[MethodDeclaration] '=' value=Expression;

In the presence of multiple methods with the same name, the scope provider will return descriptions for all methods (regardless of whether or not they are applicable for the given parameter types).

During debugging, I noticed that the DefaultLinkingService at one point calls IScope.getSingleElement, which results in binding to the first MethodDeclaration, which may or may not be the correct one:
	at fxxx.scoping.FxxxScopeProvider$1.getSingleElement(FxxxScopeProvider.java:542)
	at org.eclipse.xtext.scoping.impl.AbstractScope.getSingleElement(AbstractScope.java:109)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:115)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:266)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:237)
	at org.eclipse.xtext.resource.persistence.StorageAwareResource.getEObject(StorageAwareResource.java:100)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:209)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:269)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1516)
	at fxxx.language.impl.ReferenceImpl.getValue(ReferenceImpl.java:74)
	at fxxx.language.impl.ReferenceImpl.eGet(ReferenceImpl.java:119)

I realize that since the grammar calls for resolution to one specific element, i.e., [MethodDeclaration], that some disambiguation needs to happen at some point (like picking the "first" matching element, whatever that means, specifically).
So, I'm assuming that one option for supporting overloaded methods would be to introduce a custom linking service, that, instead of just picking the first, analyzes the argument types and then picks the correct method based on those.
Is that the recommended solution for supporting overloaded elements in Xtext or is there some other best practice I should follow?
Re: Supporting method overloading [message #1853928 is a reply to message #1853926] Sun, 24 July 2022 14:22 Go to previous messageGo to next message
Rubén Porras Campo is currently offline Rubén Porras CampoFriend
Messages: 64
Registered: July 2009
Member
Hi Mirko,

that is what I would do, inject a custom service and implement your own org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(EObject, EReference, INode)

Regards
Re: Supporting method overloading [message #1853929 is a reply to message #1853928] Sun, 24 July 2022 16:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7564
Registered: July 2009
Senior Member
Hi

Yes. That is what OCL does. If your language supports templates, you will probably need to carefully sequence your resolutions so that you know the templates types before you attempt to resolve them as types of templated operation parameters. Otherwise expect many cyclic resolution failures.

Regards

Ed Willink
Re: Supporting method overloading [message #1853938 is a reply to message #1853929] Mon, 25 July 2022 06:28 Go to previous messageGo to next message
Mirko Raner is currently offline Mirko RanerFriend
Messages: 120
Registered: July 2009
Location: New York City, NY
Senior Member
Thanks, Rubén and Ed, implementing a custom linking service did the trick (at least for the use cases that I'm currently looking at).
Re: Supporting method overloading [message #1853942 is a reply to message #1853938] Mon, 25 July 2022 09:21 Go to previous message
Elie Richa is currently offline Elie RichaFriend
Messages: 72
Registered: February 2016
Member
Hello,

Another solution I thought of is using a org.eclipse.xtext.scoping.impl.FilteringScope at the bottom of your scope chain. So for example in your custom IScopeProvider, for Invocation.target you would analyse the arguments of the invocation, determine their types and construct a FilteringScope where the filter matches the types of the call side with the types on the declaration side.

However I don't know how that would interact with the fact that determine the argument types also involves performing a resolution. It could work out of the box, or ultimately if resolutions need to be performed in a certain order (e.g. first simple expressions, then call expressions) then indeed you would need to customize the linking service.

Regards,


Elie Richa, Ph.D
Software Engineer, AdaCore
https://www.adacore.com
Previous Topic:Xtext error when used as a tool plugin
Next Topic:_trace file Debug location data path different on eclipse incremental build and maven
Goto Forum:
  


Current Time: Tue Jan 31 06:13:26 GMT 2023

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

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

Back to the top