Re: [emf-dev] ESetting/EOperation Delegate

[Achim Demelt <a.demelt@xxxxxxxxxxxxx>]

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