Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' work

["Eric Moffatt" <emoffatt@xxxxxxxxx>]

Whew, now this is a good discussion! Where do I start..;-).

Ed's very ably answered my concerns about the size of the EMF core components and all I can say is 'Beauty!". I'm still interested (as are we all it seems) in having something more concrete to kick around/analyze...

Tom, the current model's implementation, ModelElement, is a vanilla-flavored "Property Bag" (i.e a set of 'named' properties you can get or set) with a few basic frills such as a basic introspection capability and maintaining ownership relations. A special type of ModelElement, ModelDomain implements the listening protocol. It's simple....and that's part of the point.

I'm very interested in seeing a plug-replacement for the current model implemented in EMF. this would answer the question "can EMF do the simple things simply?". Treat the current ModelElement and ModelDomain as 'API' so the current demo should run the same as it does now (for better or worse...;-). I'm more than willing to help out in this exercise....

Note that I am -not- saying that this would be the final API but I think it should be treated as 'close'. Ed, I'm one of those pseudo-purists...for the clients we want to con into using this I'm highly in favor of providing the absolutely simplest API that can provide the necessary capabilities (regardless of the implementation). Rather than exposing EObject directly how about a method that returns the ModelElement's underlying 'implementation' object (something like "Object accessImplementation()", sort of like C's 'escape to assembler'..;-) ? This would keep the API implementation neutral while still allowing those 'in the know' to do their tricks (note that this would also apply to my current IMemento ScopedPreferenceStore and IConfiguration element wrappers).

BTW, if we decide that we need concrete API for the particular 'classes' of element we have (like "Stack" and "MenuItem") that provide accessor methods I'd recommend that these be -generated- from the model. I'm also a 'don't write boilerplate' zealot and this is a classic case.

Kevin, I think we'll be in a better position to judge once we get this.
We're walking a line between size/complexity and capability; the
current implementation is small, simple and sufficient unto the
day...today. However I don't think we want to be in a position where we
have to devote effort into extending it. Having EMF backing the API means that all those 'enhancement' requests we get for the model just turn into exposing more of EMF's underlying capabilities. As long as it's not too costly and we can adequately hide its implementation details from our clients I think it's a win.

I'm going back to bed, I'm under the weather today. Tom, let me know if there's anything I can do...Monday...

Onwards,
Eric