Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Re: Avoiding Bloat

Wow, this thread has reminded of how incredibly complex this problem is.  Two completely different and valid perspectives:

Perspective A: the guys who maintain a framework
  - Since APIs are forever, grow them carefully, since to do otherwise introduces code we can never get rid of, which all applications must pay for forever.

Perspective B: the guys who consume the framework
  - The more you expose as API for me, the more I can reuse. This avoids code duplication, resulting in smaller applications.

The problem of course is that its difficult to have people reuse something if the contracts aren't clear, and these often only become clear through usage, which can take several releases.

This suggests a model whereby APIs must evolve.  We've already talked about avoiding handing out interfaces for others to implement, lesson learned there (ugh).  I think a good thing we've done though is marked APIs as provisional for a period.  However, often the APIs are only provisional within a release.  Maybe we need to think of ways of expanding this kind of model over a longer period. For example, with CVS, its probably *now* ok to go and open up more API, because the reality is, the stuff's not going to change a lot because for one we understand the problem well now, and for another nobody wants to mess with code that works.  On the other hand, by now the copies have been made so who'd go back and refactor to use the new API? (Assuming we can actually either remember or detect the copies).


Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/16/2008 09:16 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

[eclipse-incubator-e4-dev] Re: Avoiding Bloat

John Arthorne schrieb:
> [...] Go wild early on in the development cycle and add what you
> want, but as the release approaches, only "graduate" API that is
> proven. I would even advocate some kind of review by project leads
> for any significant new API, where the API designer has to
> demonstrate that the API is platform quality, is thoroughly
> documented, and has multiple clients using it before it gets approved
> for release as real API.

I'm afraid that this can turn into a boomerang. Having too less and too
restrictive APIs introduces a different kind of bloat. For example, just
look at CVS and JDT. There are quite a bunch of plug-ins out there which
simply duplicated code from those components to mimic functionality
offered by them. Unfortunately, not all of them keep up with the
optimizations which happen continuously in subsequent releases in CVS
and JDT.

Making a decision here is certainly not easy.


Gunnar Wagenknecht

eclipse-incubator-e4-dev mailing list

Back to the top