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,

Comments below.


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



eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/24/2008 06:10:03 PM:

> Ed Merks wrote:
> > I would also assert that that EObjects really do feel just like DOM.
>
> Yes it does. But as Eric pointed out, there are a already DOM-like
> interfaces in eclipse:
>
>    org.eclipse.ui.IMemento
>    org.eclipse.core.runtime.IConfigurationElement
>    org.eclipse.jface.preference.IPreferenceStore
>    org.eclipse.jface.dialogs.IDialogSettings
>    org.eclipse.debug.core.ILaunchConfiguration
>    org.eclipse.core.databinding.observable.value.IObservableValue
>    ... (I am sure I forgot some)
>
> And I would add reflective EMF to that list. Only EMF and IObservableValue
> support change propagation.


Do you think we have enough yet, or would another one or two more on the list be good?  :-P

>
> I am a great fan of reflective data-structures. And I would love to see
> a unification of all the different DOM like data-structures. If we can
> adapt all of the data-structures to EObject then we would have a common
> reflective API. Unfortunately the EObject API is not as easy to use as
> say IMemento. One of the problem is that you have to have a metamodel
> in order to create instances. But even IMemento is hard to use.


This easy to use thing is something that's all too often like beauty, i.e., it's in the eye of the beholder.  As with architecture choices in general, what's unfortunate from one perspective ends up being fortunate from another.  If this were not the case, the simple obvious solution would have arrived years ago and the interesting conversations would have moved to a different topic.

>
> When to use reflective style and when java interfaces?
> ------------------------------------------------------
>
> Reflective API is great for:
>   - serialization
>   - generic UI
>   - databinding
>   - data driven UI
>   - scripting
>   - verification ,
>   - code generation (based on a model)
>   -...
>
> Reflective access gets very difficult if it is used in hand-written
> code. In those cases interfaces are much better.


Things like "very difficult" is just not quantifiable.  I agree that reflective is good for generic applications and, in constrast, when you know specifically what you are dealing with, then specific APIs end up being much nicer and more intutive.  An important principle is to support both, preferrably without one detracting from the other.

>
>
> MagicInterface
> --------------
>
> Some years ago when I figured out that there are so many reflective
> interfaces in eclipse I thought, how can I unify them and make all
> of them type safe. Reflective interfaces are great for generic
> tools like my generic editor (http://tinyurl.com/4rbe5j). However
> using reflective interfaces "by hand" is annoying. It is much better
> to use real interfaces. But with EMF, you have to create a meta-model
> and then generate a whole bunch of code. Which is also inconvenient.


It's inconvient to be specific when you don't want to feel bounded by today's choices.  Keep in mind that EMF doesn't require you to generate any code for your model.  That's your choice when you've decided your model is static enough to warrent specific APIs. Those APIs are something the specific clients our your model are generally going to prefer.  As you pointed out, generic interfaces are not so fun to use.  Otherwise we'd all be ecstatic to have DOM or a hash map and never want for more.

>
> So, I invented what I called MagicInterface.


I feel a slight of hand coming on! :-P

> The idea is that you
> write the data-structure as interfaces and there is some magic
> that binds the interface to the underlying DOM like representation.


I wonder if this will be like an EClass whose behavior you can emulate dynamically or for which you can generate an interface and an implementation class?

>
> Let's stick with IMemento. Some code from org.eclipse.ui.internal.FastViewBar:
>
>      public void saveState(IMemento memento) {
>          memento.putInteger(IWorkbenchConstants.TAG_FAST_VIEW_SIDE,
> getSide());
>
>          Iterator iter = viewOrientation.keySet().iterator();
>          while (iter.hasNext()) {
>              String next = (String) iter.next();
>              IMemento orientation = memento
>                      .createChild(IWorkbenchConstants.
> TAG_FAST_VIEW_ORIENTATION);
>
>              orientation.putString(IWorkbenchConstants.TAG_VIEW, next);
>              orientation.putInteger(IWorkbenchConstants.TAG_POSITION,
>                      ((Integer) viewOrientation.get(next)).intValue());
>          }
>      }
>
> With MagicInterface you'd create an ad-hock interface that represents
> you data-structure (very much like the EMF annotated java):


Or perhaps it's like the demand created meta data describe in

I.e., just create an "element" or "attributes" to fit into a "wildcard" as the need arises.

>
>     interface FastViewState extends MagicInterface {
> //MagicInterface is empty marker interface
>          int getFastViewSide();
>          void setFastViewSide(int side);
>          Orientation[] getOrientation();
>          Orientation addOrientation();
>     };
>     interface Orientation extends MagicInterface {
>    String getView();
>          void setView(String view);
>          int getPosition();
>          void setPosition(int pos);
>     };
>
> With the magic interface and the memento you go to the MagicFactory
> (today I'd call it MagigAdapter) and it will create you an
> implementation (based on java.lang.reflect.Proxy):


I've played with creating implementation classes using Java dynamic proxies on the fly, but at the time they were horribly slow.  It's a good way to avoid the static byte code for impl classes though...

>
>      public void saveState(IMemento memento) {
>        FastViewState state=(FastViewState )MagicFactory.
> cast(FastViewState.class, memento);
>        state.setFastViewSide(getSide());
>
>          Iterator iter = viewOrientation.keySet().iterator();
>          while (iter.hasNext()) {
>              String next = (String) iter.next();
>              Orientation orientation = state.addOrientation();
>
>              orientation.setView) next);
>              orientation.setPosition( ((Integer) viewOrientation.
> get(next)).intValue());
>          }
>      }
>
> The advantage is, that you have real interfaces (refactoring is your friend)
> but no overhead in generating a model.  Sure, this does not scale, but it
> makes your code a bit more readable. Instead of ad-hoc string properties,
> it uses ad-hoc interfaces.


It sounds much like XML Schema wildcards and then after the fact deducing a more specific type based on the actual properties set.  I wonder though at what point you'll have decide what properties are enough?  I wonder if the overhead in generating a model something that needs to be avoided in the first place.  There are definitely performance benefits to having one.

>
> Well and if you want to save the state as IDialogSettings, just use
> the MagicFactory to convert the dialog settings to magic interfaces.
> Any of the DOM mentioned above are all used in the same way. To add
> support for a new DOM type, all you have to do is to implement my
> special version of a simple interface called IDataStore.


It's almost like XMLTypePackage's AnyType, which is the analog of XML Schema's xsd:any.  It's just like DOM and you can stick pretty anything into it.  It could be data for which there is no schema, or data for which you have well-defined schema...

>
> The implementation is based on naming conventions. I also had a version
> where you could give additional hints to the underlying implementation
> using final attributes (I did this long before jdk1.5 and annotations existed)
> using fluent interface (http://en.wikipedia.org/wiki/Fluent_interface)
>
>      final MagicMember name=new MagicMember().setDefault("default-value");
>      String getString();
>
> But my colleagues thought this is too much complexity, so I removed it.


Didn't anyone get annoyed by it being Magic? :-P  I know people have even found the "E" annoying.

>
> Summary
> -------
>
> Reflective access to data-structures is great when used by frameworks in
> a generic fashion. In hand written code, should use interfaces instead.


This assumes that you don't write hand written code that does generic things that applies for all models.  So it's not generally true.  In the modeling world, people do serialization, search, compare, equality, change recording, and an endless set of cool things using generics.  They also do an endless set of things against specific APIs that have full knowledge of the model.  Both things are useful and needed.

> EMF is great for both. Unfortunately, it is not really simple to be used
> in an ad-hoc way (like Magic Interfaces)


I'm not sure I agree with that.  I firmly believe that simplicity is like beauty.  It's just not easy to pin down.

> and it is too hard to be used
> in in a reflective way, because you have to define a meta-model first.


This isn't true either, and it mixes the issue of who is defining the meta model and who is writing the specific or generic code.  If you want generated interfaces, you definitely have to define a meta model.  In fact, writing an interface is writing the metamodel, so you're pretty much doing both at once.  Reflective code assumes some type of meta model.  The more metadata you have, the more constrained the types of things you can do.  If those constraints prevent you from doing meaningless or incorrect things then they are good.  Making it easy to produce nonsense data is a disserivce.  So as always, it's a balance act between extremes.  DOM lets you make syntatic nonsense easily.  With strongly typed Java it's much more difficult to use reflection to create an instance, but the instance you do create is inherently more structured.

> (I have a solution to that too, but that's maybe too much for this
> mail)


I'm skeptical that anyone will come up with something that isn't much like all the things that have come before...

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

Back to the top