| Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4... |
McQ,
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 09:40:11 AM:
> Ed Merks wrote on 04/24/2008 08:16:43 AM:
> > 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.
> >
> Whoa! The decision to use *any* part of EMF *must* be based on it
> being the best technical solution.
The presence of a large established community with a wide range of useful services is a technical reason, though obviously a social one as well. How important that one technical reason is weighed against all the other important technical considerations is of course subject to debate. Likewise and in fact more so for social issues. But it is important to keep in mind that communities are made of people and people, however much they like to think they are driven purely by facts, are just as often driven by social considerations...
> We're already having that
> technical discussion, which is great, so I don't think using the
> "Come on, all your friends are doing it" argument is a strong point.
In my opinion a number of very weak points have been made, but I find it not all that useful to tell someone their point is weak because people don't tend to react well to that. So generally I try to ignore the weak points or provide a counter points.
>
> From my POV, having a separation between specifying the API that we
> *need* and using an underlying, more general mechanism that
> implements it is a no brainer.
The question is defining what we really need and being sure those needs will never grow or change. I've seen time and time again people claiming not to need something only to discover later that they do need it when they get farther along. This is how simple things grow complex over time and how many different solutions to the same problem will often tend to converge on something where the two are only different superficially but not fundamentally.
>
> The way to win the EMF argument is to define the API, then hold EMF
> up against it and say "See this is smaller, faster, better tooled,
> handles concurrency better, etc.". Honestly, how hard can it be to
> beat hashtables-of-strings?
It seemed there was an explicit constraint put in place that EMF APIs must not be surfaced. That's based on my reading of the statement:
I also think that there should be -no- EMF classes/ifaces in the modeling API (including the event notification).
I agree with the approach you've just outlined, but I didn't get the sense that a comparison followed by a choice was the approach being proposed before your note. It may well be the best approach to ensure that a non-EMF implementation can underly the model, but my experience tells me that this is going down the path of defining yet another metamodel so I'd like to see that decision made with a great deal of careful consideration rather than as a no brainer...
>
> McQ._______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev