Re: [xtext-dev] Content Assist in Xtend

[Sven Efftinge <sven@xxxxxxxxxxx>]

>
Hi Jan,

> I've just committed the first shot at the xtend interface for  
> content assist. There's a new plug-in, so make sure you update your  
> WS using the team project set.

Cool! Great idea to have a separate plug-in for all the xtend APIs.
> Xtend content assist is always generated but disabled by default. To  
> enable it, override the IContentAssistInvocationHandler service for  
> your language as done in
> /org.eclipse.xtext.ui.common.tests/src/org/eclipse/xtext/ 
> testlanguages/ContentAssistTestLanguageUiConfig.java

We may want to provide a switch in the generator to tell whether you  
want Xtend API or Java API in general?
I think the Xtend API is very important for acceptance specifically  
for migrating oAW Xtext users, while we will always have much better  
scalability and performance with the Java-based APIs. So both ways  
should be equally supported.

> Currently, I use very bad pattern in the ui.common.tests to recycle  
> the tests from the Java impl. I haven't introduced a service in the  
> generator yet, as it would collide with the Java CA. We should find  
> a common solution here.

Yes, why do you want to reuse AbstractProposalProvider? I thought that  
most of it's implementation is dedicated to simulate polymorphic  
dispatch, which in the case of Xtend is handled by Xtend itself, isn't  
it?
I'ld prefer to have an XtendProposalProvider which is configured with  
an Xtend file.
I'm not sure whether the Invoker abstraction is that useful.

> Some more observations:
> - In Xtend, dealing with a JavaMetamodel and an EmfRegistryMetamodel  
> for ecore in parallel causes a lot of casting errors. You can work  
> around that by delegating some calls to Java to perform the casts  
> e.g. from ecore::EObject to org.eclipse.emf.ecore.EObject.  
> Reordering the metamodels in the ExecutionContext didn't help  
> either. Maybe we find a better solution.

I see two possibilities:
1) we fix Xtend so that we don't have these problems (if possible)
2) we introduce EClasses for all the JavaAPi and translate them in the  
framework

Any other ideas? What would you prefer?

> - Overriding a service in the configuration looks horrible compared  
> to the initial deifnition. Maybe we should improve the syntax here.

Heiko is taking care of the dependency injection stuff.

> -  
> org 
> .eclipse 
> .xtext 
> .ui 
> .common 
> .editor 
> .contentassist 
> .impl.AbstractProposalProvider.completeAssignment(Assignment,  
> IContentAssistContext) sometimes produces strange method names when  
> the default alias is used. Someone has to investigate.

I guess, we need a bug report for this. ;-)

thanks,
Sven