McQ,
Comments below.
Ed Merks/Toronto/[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
905-413-3265 (t/l 313)
[EMAIL PROTECTED] 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
> [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
