Michael,
Comments below.
Ed Merks/Toronto/[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
905-413-3265 (t/l 313)
[EMAIL PROTECTED] 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
http://www.theserverside.com/tt/articles/article.tss?l=BindingXMLJava
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
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
