Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...

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....

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.

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);

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);
        }
        ....
   }

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;
        }

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

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)....

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....

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....


Michael


Back to the top