[
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...
|
McQ,
I'm definitely aware that EMF's core runtime likely contains some things that aren't needed in all cases. It's likely though that a good fraction of the Eclipse applications are using EMF already, based on the EclipseCon survey and the download stats on the Ganymede packages:
I would also assert that that EObjects really do feel just like DOM.
And I would argue strongly that DOM is not nealy as simple and folks like to believe. The amount of time I have to explain basic DOM things to people continues to surprise me. For example, the mysteries of xmlns prefix scoping seem to escape even people I assume to be experts. The listener model is far from trivial. So if being as good as DOM is our bar, it's a very low bar indeed, only slightly higher that the hash map bar. :-P
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 11:14:16 AM:
> Ed,
>
> You have seen us make these mistakes before. I get it. But you need
> to at least consider the possibility that the full generality of
> EMF, after years of it being applied to increasingly general
> problems might not *always* be required.
>
> In any case, if we are going to talk about communities, shouldn't we
> be trying to end up with something that "feels" like accessing the
> browser DOM from _javascript_ (+ listeners)? I'm certain that people
> who understand *that* dwarf all Eclipse communities.
>
> McQ.
>
>
> [image removed] Ed Merks---04/24/2008 10:28:19 AM---McQ,
>
> Ed Merks/Toronto/IBM@IBMCA
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> 04/24/08 10:20 AM
>
> Please respond to
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
> [image removed]
> cc
>
> [image removed]
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse-
> incubator-e4-dev-bounces@xxxxxxxxxxx
>
> [image removed]
> Subject
>
> [image removed]
> Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...
>
> [image removed]
>
> [image removed]
>
>
> 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
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> [image removed] _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
