On Thu, Apr 17, 2008 at 11:15 AM, Michael Scharf < [EMAIL PROTECTED]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
