Scoping and Overload Resolution [message #1733850] |
Wed, 01 June 2016 13:21  |
Eclipse User |
|
|
|
Hi,
I have a DSL which allows function/operator overloading. My resource description strategy in combination with my qualified name provider exports publicly declared operators in the index. For example
package x.y.x
public op (int x, int y) -> int
would be exported in the index as 'x.y.z.plus' and life is good.
Now that life is fine and dandy we can go and retrieve them from the index. Currently I allow any operator combination, for example AnyType1 = AnyType2 + AnyType2 and let my type system sort it out. It calls a subsystem that manually queries the index, filters the results on operator name and finds a match. So for something like
We are looking for all publicly exported operators with name 'plus' and matching formal parameter types
val typeArg1 = expr1.type
val typeArg2 = expr2.type
operator = findBinaryOperator("plus", typeArg1, typeArg2){
objectDescriptions = findAllTheCandidates
//!!!!! Resolve all the descriptions to match formal parameter types
return matching op (or not)
}
The exclamation mark overkill on the resolve proxies part is where I feel it is shaky (although it works fine). Because, while the resource description strategy limits the index size to a minimum (unless the user is declaring 100s of publicly exported overloaded operators in each file in which case he deserves all he gets in my opinion) the proxies may still be splayed across many resources.
It would be nice if we could filter the descriptions without having to resolve all the candidate proxies either by
- Name Mangling
- using EObjectDescription.UserData
These boil down to more or less the same thing, encoding the formal parameter types in the naming. With name mangling we get a unique name for each overloaded operator and with user data we get multiple names but each with unique user data. My concern is that in trying to encode the formal parameters (which will cross-reference types naturally) I will need the FQN of the type references. Now, although these must have already been resolved by my scope provider (or if not the whole tree is invalid anyway so who cares) is it always safe (or indeed never safe) to call get FQN on the type refs of the formal parameters when creating the EObjectDescription? (Given that the operator declaration has been linked and validated already). For example,
unaryop name= ID (typeRef = [type] )
then in creating the FQN or EObjectDescription call
operatorFQN = stuff + typeRef.getFQN
Or is this going to get me in a pickle?
So the questions remaining for me are:
- What has everyone done/tried
- Is there a standard 'xtext' way of doing this
- Is it safe to call getQualifiedName on the parameter type cross-references during index export
[Updated on: Wed, 01 June 2016 13:23] by Moderator Report message to a moderator
|
|
|
Re: Scoping and Overload Resolution [message #1733852 is a reply to message #1733850] |
Wed, 01 June 2016 13:33   |
Eclipse User |
|
|
|
What has everyone done/tried
for sure
Is there a standard 'xtext' way of doing this
the standward way is not to do this but to use xbase
Is it safe to call getQualifiedName on the parameter type cross-references during index export
no it is not - at least for non local cross references. xtext does indexing first and then resolves cross references
|
|
|
|
|
Re: Scoping and Overload Resolution [message #1733859 is a reply to message #1733857] |
Wed, 01 June 2016 13:48  |
Eclipse User |
|
|
|
Yes that was a thought I had too but they may be import based. It's probably not too bad just fetching the operators from the index and caching the results. How bad can it be (as the captain of the Titanic was heard to say)?
|
|
|
Powered by
FUDForum. Page generated in 0.04194 seconds