| [incquery-dev] xcore & incquery integration |
|
Hi I have started to deal with the Xcore & IncQuery integration issue and I have a few notes/questions: -Please take a look at the proposed syntax: https://gist.github.com/istvanrath/5514021. Basically there are two things that should be "added": support for imports and the special derived feature syntax. -Imports: actually, the current language allows to reference any JvmType in an import and this results that if the given Xcore project also has IncQuery nature then the PatternModels defined in some eiq file will be also available for import. This slightly differs from the desired syntax as this will use a String representation in a fully qualified id form (not like the file name 'Library.eiq'). I guess this can be customized for example in the proposal provider, but haven't really found a solution yet*. -The derived feature spec: the current language of Xcore does not allow to write something like 'derived Int numberOfBooks spec library.numberOfBooksOfWriter'. The problem is with the spec keyword. If I create an other language (for example 'IncQueryXcore' which extends the Xcore language) then I can create a new language element XIncQueryDerivedFeature, which has a definition like: XIncQueryDerivedFeature: {XIncQueryDerivedFeature} 'incquery-derived' type=XGenericType multiplicity=XMultiplicity? name=ID 'spec' (pattern=[patternLanguage::Pattern]) (';')? ; Here, note that the keyword is 'incquery-derived', not 'derived'. Using the latter keyword would cause that the antlr generator throws an error that the given language is not LL(*), because an XStructuralFeature (from Xcore) can also start with the 'derived' keyword. -@Istvan: The code that is generated by Abel's derived feature generator could be used in the body of an 'original' xcore derived feature (it uses xbase). I just copied to code to the body but could not execute it at the moment because of the xtext 2.3 - 2.4 problem. *Ed Merks also suggested that if we need some better customization then the best would be to extend the xcore language and create a new one. The problem for me here is that xcore uses the .xcore file extension and the editor is also registered for that. If we create a new language which is also registered for the xcore file extension then which editor should be used? Such problem does not arise in the IncQuery context because the base patternlanguage project does not contribute anything, except the generated genmodel file. I also asked around some folks at itemis and they have also not heard about such thing (two editors/generators for the same file extension). Cheers, Tamas |