Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...

[Ed Merks <merks@xxxxxxxxxx>]

Michael,

Comments below.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)



eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/17/2008 12:48:28
PM:

> Tom Schindl wrote:
> > Michael Scharf schrieb:
> >> I think using a formal model is a great idea. It allows to reason
> >> about the model and you can use all the modeling tools for
> >> the model. However I dislike the fact that the generated EMF
> >> code makes all objects extend EObject. EObject adds a set
> >> of (reflection) methods that are not relevant for the
> >> domain (of e4 presentation). I think the better approach
> >> would be to use something like IAdptable to adapt a
> >> presentation object to EObject (or to something that
> >> allows reflection).
> >>
> >
> > We already talked about this. EMF allows you to generate the interfaces

> > without any Ecore specific things.
>
> Good this solves the interface problem.
>
> But we are still stuck with the EMF reflection. I have
> not (yet) seen an implementation of the EMF metamodel that
> works on POJOs or scripting objects. The openArchitectureWare
> approach was designed to work with different (meta) model
> implementations....

I'm not sure how it's possible to make POJOs produce notification. Or how
to make them support things like containment, which is clearly important
for this particular model.  In any case, having an EMF implementation
doesn't preclude anything else you might want to adapt it to.

>
> The problem is that the EMF reflection makes the assumption
> that each model object Is-A EObject. That makes it very
> hard to use adapters, because of object identity problems.

You can call it the problem but I will argue that's what bring order to the
chaos.  And nothing about EMF precludes adapters.

>
> The openArchitectureWare approach separates the reflection
> from the model. To get a value of a model object you do:
>
>      Type type=metamodel.getType(pojo);
>      Property property=type.getProperty("myProperty");
>      Object value=property.get(pojo);

Do these models produce notification?  What are Type and Property?  Are
these modeled as well?

>
> To access properties, the original object is passed in
> as a parameter. Very much like the IContentProviders
> in JFace.
>
> The EMF metamodel assumes a Is-A relation:
>
>      EObject emfObject=(EObject)adapterFactory.getAdapter(EObject.class);
>      EStructuralFeature property=record.eClass().
> getEStructuralFeature("myProperty");
>      Object value=emfObject.eGet(property);
>
>
> The problem is that you would have to create an
> adapter for each POJO:
>
>     class EObjectPojoAdapter implements EObject {
>          final Object pojo;
>          EObjectPojoAdapter(Object pojo) {
>             this.pojo=pojo;
>          }
>          public Object eGet(EStructuralFeature feature) {
>              return getTheFetureOfThePojo(pojo,feature);
>          }
>          ....
>     }
>

That's only true if you want POJOs to be reflective EObjects, which isn't
necessary.

> What should the EObjectPojoAdapter.eGet return,
> if the returned value is another model object?
> EMF expects it to be an EObject. Therefore the
> eGet method would look like:
>
>          public Object eGet(EStructuralFeature feature) {
>              Object result=getTheFetureOfThePojo(pojo,feature);
>              if(feature instanceof EReference) {
>                  result=decorateAsEObject(result);
>              }
>              return result;
>          }
>

EMF fully supports data types that can yield features of any type.  It's
just that if they aren't EObjects, you can't use reflection on them and you
can't expect them to produce notifications.

> And decorateAsEObject could implement a weak map that maps you
> model object with the EObjectPojoAdapter.... But I think this
> is somewhat clumsy...

Maps are huge big space hogs and map lookup (Map.get) is slower than EMF
reflection, EObject.eGet(feature).

>
> The other problem is that once you have the EObjectPojoAdapter,
> it is hard to get to the underlying pojo (AFAIK, there is no
> method in the EMF meta-model that gives you acces to the "real"
> object, because of the build-in Is-A assumption)....

I can't imagine wrapping being a great solution anyway but there is suppot
for EStore which can delegate all data access to some other arbitrary
representation and in that case, the EObjects are just husks or facades
that contain no data at all.  CDO is exploiting this approach.

>
> Hmm, well maybe this discussion is a discussion for the EMF
> newsgroup, and I am sure Ed can't hear this complaint anymore
> because this has probably been discussed a thousand times....

Actually, I don't hear this complaint much at all anymore, because my most
common reaction is, if POJOs are so great, why are you here with a problem
that you need to solve.  Why don't you just use Java relfection?  Oh, you
need notification, serialization, containment, bidirectional references, as
well defined meta model, integration with other models...

>
> BUT! I still think a reflection layer that is not based on
> the Is-A model would be a useful addition to the eclipse
> platform....

I think the fact that notifications are desired and that models which
produce notifications don't grow out of POJOs along with the fact that data
integrity for things like containment is needed and also doesn't grow out
of POJOs makes this abstract high level desire kind of incomplete.
Certainly what you describe, if things like containment and notification
aren't needed at all, could be propped up by EMF or by some alternative
implementation but it's not so clear if it's addressing a broader view in
the context of a UI where changes to the model are expected to induce
changes on the screen...

>
>
> Michael
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev