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


**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'm not sure. Do you suggest that we translate EMF-Notifications into another Event-System. I'd like to stay with EMF-Notifications but let the clients register themselves not directly on the model but on point which dispatches events coming from the model to the clients registered. 

Tom

--
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                               leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3    A-6020 innsbruck      phone    ++43 512 935834

Back to the top