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

[Ed Merks <merks@xxxxxxxxxx>]

Eric,

I can see appeal of hiding behind a new API. It creates a sense of purity and isolation that seems like goodness on the surface. But of course hiding behind a new API requires thought about exactly what's in that API. I.e., what methods are all available on Type and Property? How is a notification represented to ensure that the information it provides is 100% complete? Naturally one could look to all the EMF APIs (or perhaps the SDO ones) for that information and duplicate it, while presumably simplifying it, to produce another EMF-like API. This would of course result in yet one more new API (a metamodel), in addition to the new UI model's API itself, and unfortunately that seems highly unlikely to produce a result that's in actual fact simpler or smaller since those traits generally come from reuse of common designs and existing byte code. With regard to IMemento, EMF already fully supports XML persistence of instances, so I'm not sure there's much need to implement that in yet another way as well. Also, Marcelo has prototyped a JSON serialization for EMF instances, in case that's a valuable thing...

Keep in mind that there is a very large modeling community exploiting EMF models as well as providing services around them, so in terms of growing a large e4 community, leveraging existing ones seems like a good approach, at least on the surface. For example, I could imagine designing a general purpose event model, analogous to the current change model, for recording model change events in order to support playback and reverse. Such a thing would have broad applicability across the model space, which is of course one of the advantages of having one common metamodel to bind all the other models...


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


"Eric Moffatt" <emoffatt@xxxxxxxxx>

"Eric Moffatt" <emoffatt@xxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/23/2008 03:03 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...

On Thu, Apr 17, 2008 at 11:15 AM, Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx> wrote:

[snip!]
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.

Michael, I really like the idea of using an Adapter pattern to gain access to any underlying implementation details. I also think that there should be -no- EMF classes/ifaces in the modeling API (including the event notification). Using an adapter (rather than the more specific 'getImplementation' method) opens the door for some very interesting cross-model capabilities. For example model implementors (i.e. EMF) could not only support 'adapting' a ModelElement to EObject but could also support 'adapting' to a databinding 'Observable' (or JSON...).

Another example (that I might use) is to adapt a particular Model to 'IMemento' so that I can integrate it with the existing API structure (all of our save/restore code uses IMemento as the persistence API).

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