Wow, this thread has reminded of how
incredibly complex this problem is. Two completely different and
Perspective A: the guys who maintain
- 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 more you expose as API
for me, the more I can reuse. This avoids code duplication, resulting in
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
John Arthorne schrieb:
> [...] Go wild early on in the development cycle and add what you
> want, but as the release approaches, only "graduate" API
> 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
Making a decision here is certainly not easy.
eclipse-incubator-e4-dev mailing list