Since Xcore currently lacks a proper extension mechanism (AFAIK, but also supported by my private conversations with Ed), I don't think we have any better choice than to first create an Xcore derivative, which is intentionally differentiated from the original Xcore e.g. by the new file extension.
If the approach is then deemed interesting enough for further continuation, then we can propose an extension mechanism to Xcore which would allow a more seamless integration while keeping the original unaltered.
--
Istvan RATH, PhD
Research fellow Budapest University of Technology and Economics
Fault Tolerant Systems Research Group
On Monday, June 3, 2013 at 10:13 AM, Tamas Szabo wrote:
Actually, I think it would solve the
problem. But with this file extension this whole integration thing
doesn't go as seamlessly as it was planned to, right?
I think it would be even better to change the file extension
to something new, e.g. ".xcoreiq"
Would this solve the problem?
--
Istvan
RATH, PhD
Research
fellow
Budapest University of Technology and Economics
Fault
Tolerant Systems Research Group
On Monday, June 3, 2013 at 10:07 AM,
Tamas Szabo wrote:
Yes, that would be the best way to do it, but then
comes the problem with the "same file extension -
different editor and xtext artifacts" issue:
Both xcore and the modified language (with the incquery
interation) would have an own language (the incquery
related one extends xcore), mwe2 workflow to generate
the artifacts, etc.
The explicitly defined metamodel would not be an issue,
because I can define an other ecore metamodel for the
new language with just adding the additional (new) model
elements and referencing the Xcore.ecore.
On Friday, May 31, 2013 at
11:34 AM, Tamas Szabo wrote:
The idea is nice, but I am not really
allowed to modify the xcore code/language.
But can't we do it in a non-invasive way, i.e.
instead of modifying Xcore, creating a new DSL that
extends Xcore and overrides this particular rule
according to Gaben's suggestion?
I know that there is some issue with Xcore having
a manually constructed metamodel, but if you could
elaborate more on this, then perhaps we could
discuss the proposed solution better.
Istvan
--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and
Economics
-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:
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.
So if we
used there 'derived',
that would be a
keyword clash between the two
separate rules
XIncQueryDerivedFeature and
XStructuralFeature.
But do they absolutely need to
be two separate rules? Can't we
just change the
rule XStructuralFeature by adding
an _optional_ tail looking like
this:
('spec'
(pattern=[patternLanguage::Pattern]))?
And then
there would be only XStructuralFeatures,
some of which would have a "spec"
clause. So it seems to me that it
is possible to keep the simpler
syntax.
Of course, this solution may
mean that we would have to add a
validator rule to enforce that if
the feature has a spec, then it
must be marked as derived as well.
Then again, incquery-based derived
features will require a buttload
of other validators as well.
Disclaimer: I am far from
being an Xtext expert, so
forgive me if I have said
something stupid :)
