Eclipse Community Forums: TMF (Xtext) » Interfaces and classes / types are proposed where only interfaces should be proposed

Home » Modeling » TMF (Xtext) » Interfaces and classes / types are proposed where only interfaces should be proposed

Show: Today's Messages :: Show Polls :: Message Navigator

Interfaces and classes / types are proposed where only interfaces should be proposed [message #1764813]

Fri, 02 June 2017 11:47

Marco Ullrich

Messages: 14
Registered: December 2016
Location: Bayreuth

Junior Member

Hello everyone,

i have a problem with the proposal provider proposing too much.
I have the following grammar:

Program:	SubPrograms+=NamedElement*;
NamedElement:	Type |  Interface;
Type:	'type' name=ID;
Interface:'interface' name=ID ('offers' interfaces=JvmTypeReference)?;

The semantic is, that interfaces could only offer other interfaces (like in java a interface can only extend other interfaces).
Hence the proposal provider should only provide interfaces for the feature 'interfaces'

This is my inferrer.
Types are generated as nested static classes, interfaces are also nested in the main class:

def dispatch void infer(Program program, IJvmDeclaredTypeAcceptor acceptor, boolean isPreIndexingPhase) {								
	acceptor.accept(program.toClass("Main"))[
		packageName = "main" 
		program.subPrograms.forEach[ namedElement |
								
			if(namedElement instanceof Interface){
				members+= namedElement.toInterface(namedElement.name,[
								interface = true
								if(namedElement.interfaces!= null){
									superTypes += namedElement.interfaces.cloneWithProxies																		
								}
							])
			}						
			
			// Types are nested static classes						
			if(namedElement instanceof Type){
				members+=namedElement.toClass(namedElement.name,[		
					static = true
				])			
			}					
		]
	]	  
}

To achieve the desired proposal behaviour, i customized the ProposalProvider:

class MyDsl2ProposalProvider extends AbstractMyDsl2ProposalProvider {	
	override completeInterface_Interfaces(EObject model, Assignment assignment, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
		val filter = createVisibilityFilter(context, IJavaSearchConstants.INTERFACE)		
		completeJavaTypes(context, TypesPackage.Literals.JVM_PARAMETERIZED_TYPE_REFERENCE__TYPE, filter, acceptor)
	}
}

The proposalprovider now proposes all jvm-interfaces and every interface AND type that is defined by the user.
E.g. in the following program:

type myType

interface i1 

interface i2 offers Main$<ctrl+space>

<ctrl+space> displays the proposals:
Main.i1
Main.i2,
Main.myType

i1 and i2 are ok, because they are interfaces but i dont want myType to be displayed, because it is a typ (aka. a class).

Am i doing something wrong in my proposal provider?
I thought filtering for IJavaSearchConstants.INTERFACE would reduce the searchscope to interfaces?

Tanks in advance for your help! (:

Marco

Report message to a moderator

Re: Interfaces and classes / types are proposed where only interfaces should be proposed [message #1764818 is a reply to message #1764813]

Fri, 02 June 2017 12:17

Christian Dietrich

Messages: 14669
Registered: July 2009

Senior Member

hmmm

this is cause the tyes come from

if (acceptor.canAcceptMoreProposals()) {
Iterable<IEObjectDescription> allDirtyTypes = dirtyStateManager.getExportedObjectsByType(TypesPackage.Literals.JVM_TYPE);
for(IEObjectDescription description: allDirtyTypes) {
QualifiedName qualifiedName = description.getQualifiedName();
final int modifiers = getDirtyStateModifiers(context, description);
if (filter.accept(modifiers, qualifiedName.skipLast(1).toString().toCharArray(), qualifiedName.getLastSegment().toCharArray(), new char[0][0], description.getEObjectURI().toPlatformString(true))) {
String fqName = description.getQualifiedName().toString();
createTypeProposal(fqName, modifiers, fqName.indexOf('$') > 0, proposalFactory, myContext, scopeAware, jvmTypeProvider, valueConverter);
}
}
}

and this place does not seem to care about interface/noninterface (for local defined types)

i assume the modiers should be looked as well (e.g.)


import org.eclipse.jdt.core.Flags;
import org.eclipse.jdt.core.search.IJavaSearchConstants;
import org.eclipse.xtext.common.types.xtext.ui.ITypesProposalProvider.Filter;
import org.eclipse.xtext.common.types.xtext.ui.TypeMatchFilters;
import org.eclipse.xtext.ui.editor.contentassist.ContentAssistContext;

public class VisibilityFilter2 extends TypeMatchFilters.AbstractFilter {
	
	private Filter delegate;
	private int searchFor;

	public VisibilityFilter2(ContentAssistContext context, int searchFor) {
		this.searchFor = searchFor;
		delegate = TypeMatchFilters.and(TypeMatchFilters.isNotInternal(searchFor), TypeMatchFilters.isAcceptableByPreference());
	}

	@Override
	public boolean accept(int modifiers, char[] packageName, char[] simpleTypeName, char[][] enclosingTypeNames,
			String path) {
		if (delegate.accept(modifiers, packageName, simpleTypeName, enclosingTypeNames, path)) {
			if (searchFor == IJavaSearchConstants.INTERFACE) {
				return Flags.isInterface(modifiers);
			}
			return true;
		}
		return false;
	}
		
	}

can you please file a bug at xtext-eclipse on github

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator