| Supporting method overloading [message #1853926] |
Sun, 24 July 2022 07:10  |
 Mirko Raner
Messages: 125
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 #1853942 is a reply to message #1853938] |
Mon, 25 July 2022 09:21  |
Elie Richa
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
|
|
|
Powered by
FUDForum. Page generated in 0.02999 seconds
] 
Search
Help
Register
Login
Home
