[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [emf-dev] ESetting/EOperation Delegate
|
Sven, Ed,
Comments below.
> Yes, that would be really cool.
> We currently think about developing a base language for Xtext,
> supporting expressions, which can be generated to Java or interpreted.
> So by subclassing that language in an EMFatic-like language both
> generated an dynamic Ecore models should work.
>
That would be cool. The alternative would be to have two separate DSLs (one
for Emfatic-ish Ecore and one for an Xtend-ish expression language) and mix
both of them in one editor. Which is probably pretty hard to do...
> I personally would prefer one general hook (like in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130) over the several
> special ones.
> I'd like to specify guarding behavior for common (non-derived)
> features as well.
>
In the spirit of separation of concerns, I tend to prefer specialized
hooks/adapters for each distinct purpose over a "one-size-fits-all" solution.
In this particular case, I'd also argue that the scope of the extensions is a
different one. The computational behavior of derived properties and operations
is rooted at the (meta)model level, i.e. every instance of the model obeys the
same computational rules. The adapter pattern, however, and especially the one
discussed in bug 247130, applies to the instance level. IMHO, this warrants to
separate concepts.
>> We then register a special
>> EPackage.Descriptor in the Registry that instruments the meta-data and
>> attaches the appropriate EAnnotations to make use of the SettingDelegates
>> and CallDelegates.
>
> Cool, though I guess this doesn't work for generated models then, which
> would also be cool to support.
Well, yes and no.
Our current prototype implementation supports the settingDelegate/callDelegate
annotations as proposed by the current patch. If you specify the Xtend
expression in the annotation too, you can generate the model as usual, but the
relevant calls will be delegated to Xtend. So you can use the
generated_package extension point, and still make use of dynamic expressions
:-)
The approach with an ecore file and one or more .ext files, however, currently
only works for a purely dynamic model. We use a special extension point
org.eclipse.XTEND.ecore.dynamic_package, and that's the one that registers a
specialized EPackage.Descriptor. The only drawback is that these descriptors
don't get registered until our bundle is started, since the vanilla
EPackage.Registry merely reads its own extensions. To solve this, I was
thinking about an additional o.e.ecore.package_provider extension point. Upon
its activation EMF could ask these providers for additional packages that need
to be registered, in addition to those from the regular generated_package and
dynamic_package extensions.
One final note about this "purely dynamic" case: I'm thinking about generating
interfaces for these models. The EFactory will then return proxies for
DynamicEObjects that pretend to implement these generated interfaces. This
way, a developer can program against static, type-safe interfaces, while still
being purely dynamic in the back-end.
Cheers,
Achim