Re: [ease-dev] GSoC code competion commits

[Martin Kloesch <martin.kloesch@xxxxxxxxx>]

Hi,

I understand that GSOC is JavaScript only but to write code that will 
need to be changed immediately once another scripting language wants 
autcompletion may not be the best option.

The syntax parsers will not be completely different in other languages 
but e.g. Python does not have the "new" keyword for constructors. I know 
it is only a minor thing but I guess having a simple interface with a 
base implementation would be the most clean solution to avoid future 
problems. All ICompletionAnalyzers can inherit from the base class and 
will only need to define the language specific syntax analysis they 
need. I already implemented the interface and the base class and it 
looks good so far with the implementations for JavaScript and Python.

I extended the schema for the "language" extension point with a new 
element completionAnalyzer and query for it basically the same way as 
for ModuleWrappers. Since the schema is not used to perform any 
runtime-checks this will not break other script engines and offer a 
clean solution to query for it.

One thing I noticed is that the latest upstream changes seem somewhat 
wrong. You added the ContentProposalAdapter class to the 
org.eclipse.ui.view package without changing the package declaration in 
the file. If i change the package declaration to the view package the 
class will not match given interfaces so it would be necessary to move 
it to the declared org.eclipse.jface.fieldassist package. Did that slip 
through or am I missing something here? If it's just a problem for me 
then it's okay, otherwise I will also post it in a new thread to make 
others aware of this...

Best regards,
Martin


Am 2015-08-03 um 00:32 schrieb Christian Pontesegger:
> Hi Martin,
>
> Having a new interface for ICompletionAnalyzer would be a better 
> option. The scripting service is actually a singleton, hidden behind 
> an eclipse service. So it is a single point we need to change here. 
> Yet I am not sure, why you would need different analyzers for 
> different languages. First your GSoC target is javascript only, but I 
> am glad that you already think about other languages. still I guess 
> the relevant syntax to be parsed does not look different for eg. 
> python. Still if you need that interface, make a new one and do not 
> merge it with the ModuleWrapper.