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). Kevin Gunnar Wagenknecht <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/16/2008 09:16 AM Please respond to E4 developer list <[email protected]> To [email protected] cc Subject [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 -- Gunnar Wagenknecht [EMAIL PROTECTED] http://wagenknecht.org/ _______________________________________________ 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
