Skip to main content

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

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

**Break the Is-A relation and make it a Has-A realtion**

I really like here the approach that openArchitectureWare
has taken. In order to access the model via reflection,
they have a MetaModel that allows reflective access to
the model:

  http://tinyurl.com/3ummkv (javadoc)
  http://tinyurl.com/4rher7 (cvs)

The basic idea is that your model has no (public)
is-a relationship to a meta-model implementation,
but there is a kind of adapter that gives you
access to the meta-model. If we don't like to have
the adapter, then a getMetaModel() or getType()
method on the model would turn the is-a into a
has-a relationship.

The big advantage is that there is no is-a relationship
of the model objects (interfaces) to the underlying
implementation. So, you can change the meta-model
implementation without breaking clients. With the
meta-model as public part of the model you create
tight coupling that makes me feel uncomfortable.

Another advantage of a pluggable meta-model adapter is that
we could provide a rich reflective access to objects that
are not EMF objects. In addition it would allow us to
have a uniform and rich meta-model that can be used
for scripting. If objects created by scripting engines
would provide an adapter to such a meta-model, then
you can use the same meta-model interfaces as for the
EMF objects.

Similar to the plain meta-model access, there should
be another abstraction for managing event listeners
(the EMF Notifier mechanism). This would allow to
implement Eric Moffatts idea of having one central
"event funnel"...

I have only been talking about usage of modeling
inside e4. The other side is the use of meta-models
for client code. But this is another discussion
and I don't want to mix the two discussions.

Michael


Back to the top