| [xtext] conflicting meta models in xtend [message #44308] |
Tue, 19 May 2009 02:08  |
Eclipse User |
|
|
|
Hi all,
Let's say I have an Xtend file with a single extension as follows:
ext(ecore::EClass this) : this.eIDAttribute ;
This extension can now only be invoked in an execution context where the
EMF meta model is registered and also the JavaBeans meta model has *not*
been registered before the EMF meta model. I.e. the following test would
fail:
ExecutionContext ec = new ExecutionContextImpl();
ec.registerMetaModel(new JavaBeansMetaModel());
ec.registerMetaModel(new EmfRegistryMetaModel());
assertNotNull(ec.getExtension("ext", new Object[] {
EcoreFactory.eINSTANCE.createEObject() }));
This would however work if the meta models had been registered the other
way around. What is the reason for this limitation?
If I were to select the extension manually and invoke it, the invocation
would fail with an EvaluationException because it would again lookup the
property "eIDAttribute" in the wrong meta model (JavaBeans meta model)
where it's of course called "EIDAttribute".
Cheers,
--knut
|
|
|
|
| Re: [xtext] conflicting meta models in xtend [message #44402 is a reply to message #44308] |
Tue, 19 May 2009 03:17  |
| Eclipse User |
|
|
|
Hi Knut,
this is because at runtime types have to be looked up by a given object,
Xtend asks each registered MetaModel (in the order they have been
registered) if it knows the object and has a type for it.
As the JavaBeansMetaModel basically feels responsible for everything
which is not a built-in type of Xtend (i.e. String, Boolean, Int, List,
Collections, Set and the meta object types) it returns a type and
therefore the the EMFMetamodel is never asked.
So the order plays an important role by design and it's intended.
At "compile time" (i.e. when analyzation takes place) the order is also
relevant but this time types are looked up by their name, so that
there's no conflict between 'ecore::EClass' and
'org::eclipse::emf::ecore::EClass'.
Cheers,
Sven
Knut Wannheden schrieb:
> Hi all,
>
> Let's say I have an Xtend file with a single extension as follows:
>
> ext(ecore::EClass this) : this.eIDAttribute ;
>
> This extension can now only be invoked in an execution context where the
> EMF meta model is registered and also the JavaBeans meta model has *not*
> been registered before the EMF meta model. I.e. the following test would
> fail:
>
> ExecutionContext ec = new ExecutionContextImpl();
> ec.registerMetaModel(new JavaBeansMetaModel());
> ec.registerMetaModel(new EmfRegistryMetaModel());
> assertNotNull(ec.getExtension("ext", new Object[] {
> EcoreFactory.eINSTANCE.createEObject() }));
>
> This would however work if the meta models had been registered the other
> way around. What is the reason for this limitation?
>
> If I were to select the extension manually and invoke it, the invocation
> would fail with an EvaluationException because it would again lookup the
> property "eIDAttribute" in the wrong meta model (JavaBeans meta model)
> where it's of course called "EIDAttribute".
>
> Cheers,
>
> --knut
>
|
|
|
| Re: [xtext] conflicting meta models in xtend [message #44433 is a reply to message #44402] |
Tue, 19 May 2009 03:47 |
| Eclipse User |
|
|
|
Hi Sven,
Thanks for the explanation.
Cheers,
--knut
Sven Efftinge wrote:
> Hi Knut,
>
> this is because at runtime types have to be looked up by a given object,
> Xtend asks each registered MetaModel (in the order they have been
> registered) if it knows the object and has a type for it.
>
> As the JavaBeansMetaModel basically feels responsible for everything
> which is not a built-in type of Xtend (i.e. String, Boolean, Int, List,
> Collections, Set and the meta object types) it returns a type and
> therefore the the EMFMetamodel is never asked.
> So the order plays an important role by design and it's intended.
>
> At "compile time" (i.e. when analyzation takes place) the order is also
> relevant but this time types are looked up by their name, so that
> there's no conflict between 'ecore::EClass' and
> 'org::eclipse::emf::ecore::EClass'.
>
> Cheers,
> Sven
|
|
|
| Re: [xtext] conflicting meta models in xtend [message #47009 is a reply to message #44402] |
Tue, 02 June 2009 04:27 |
| Eclipse User |
|
|
|
Hi Sven,
Can you provide some guidelines on when to use the EMF meta model and when
to use the JavaBeans meta model?
Background: Internally in Xtext you seem to mostly use the JavaBeans meta
model. Thus, without thinking too much about it, I have also used the
JavaBeans meta model for my own Xtext generator fragments. This allowed me
to use some of the Xtend extensions defined by Xtext and worked out fine.
For the purpose of the generator fragments I also created some Xtend
extensions specific to the elements of my DSL, which I use in the
generator fragment (the fragment reads files conforming to this DSL).
These extensions were thus also written using the JavaBeans meta model.
Next I also wanted to use the DSL specific extensions from Check files
written for the DSL editor. This however turns out to be difficult as by
default my model objects will be identified as objects of types defined by
the EMF meta model. Apart from duplicating all extensions (which also
poses some difficulties) I can decide to use either of the meta models
exclusively. Hence the question.
The JavaBeans meta model is of course more flexible as it allows me to
navigate and use elements not defined by the EMF models. As a downside I
assume it doesn't perform quite as well as it is based on Java reflection
instead of EMF reflection. Is the gained flexibility the reason for using
JavaBeans internally in Xtext?
Regards,
--knut
Sven Efftinge wrote:
> this is because at runtime types have to be looked up by a given object,
> Xtend asks each registered MetaModel (in the order they have been
> registered) if it knows the object and has a type for it.
>
> As the JavaBeansMetaModel basically feels responsible for everything
> which is not a built-in type of Xtend (i.e. String, Boolean, Int, List,
> Collections, Set and the meta object types) it returns a type and
> therefore the the EMFMetamodel is never asked.
> So the order plays an important role by design and it's intended.
>
> At "compile time" (i.e. when analyzation takes place) the order is also
> relevant but this time types are looked up by their name, so that
> there's no conflict between 'ecore::EClass' and
> 'org::eclipse::emf::ecore::EClass'.
|
|
|
| Re: [xtext] conflicting meta models in xtend [message #47098 is a reply to message #47009] |
Tue, 02 June 2009 09:21 |
| Eclipse User |
|
|
|
Hi Knut,
Knut Wannheden wrote:
> Is the gained flexibility the
> reason for using JavaBeans internally in Xtext?
yes, exactly. It's just to allow to call Java components (e.g.
IScopeProvider) from xtend without doing error-prone cast orgies.
Regarding the performance, I couldn't see any significant difference.
We used to use the EMF meta model in Xtext code generator earlier, right
after migrating to the JavaBeans meta model executing the 'Generate All
Languages' task didn't take longer than with the EMF meta model. So I
suspect that there's not much difference.
Cheers,
Sven
|
|
|
Powered by
FUDForum. Page generated in 0.04134 seconds
Home