[
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...
|
I understand. It's not about being higher or lower than the bar, though. It's about understanding the delta between us and the bar. If we are better, but have increased the complexity for developers, then we have failed.
At some level, this is like the "20 things" argument. I'm sure (well maybe not *sure* <g>) that Eclipse provides more than 20 useful services right now, but I'm also sure that *most* Eclipse development doesn't require them. We should be talking about API in terms of the things the average developer actually must know. If EMF does other things, that's fine with me as long as I don't have to tell people about them.
McQ.
![Inactive hide details for Ed Merks---04/24/2008 01:29:55 PM---McQ,]()
Ed Merks---04/24/2008 01:29:55 PM---McQ,
Ed Merks/Toronto/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/24/08 01:23 PM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx> |
|
|
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_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
