Paul Hammant wrote: ><snip>I did this ( > >http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html > ) at the beginning of the week. > Yes Paul, I was trying to write my visuals to compliment your textual/academic material, but no idea if that goal was acheived.
My concern is that COP is not as understandable to some of us with lesser grey matter, using myself as a guide. If it can't be reduced to pictures, some of us just can't get there. Being dim witted is not always fun. I've been studying Avalon for weeks now, and I only just "got" Roles yesterday, and only because Berin had to write me an email! A more specific fear, is those like myself, who think they understand it, but spend a couple weeks designing some new component to contribute that assumes a new "ROLE" or "Work Interface" which is not based on some a set of standard API's call signatures, but instead based on their own component. So then the Paul, Leo, Peter, Berin and Federico have to either a.) break the guy's heart, or b.) tell him he has to re-write it so it works with JXXX and JYYY call signatures, and decouple his own, or c.) do it for him, or d.) just bring it in anyway. Not good choices. So how to let people know in advance and make sure that they really "got it." ? The same is true with Separation of Concerns. Most of the actual work is in the code of the implementation, but most of the VALUE is in making the ROLE or Work Interface sensible enough for future pluggability. Again, everything hinges on that interface. And because the committers already understand this obvious fact so deeply, it never gets the emphasis in the otherwise excellent and very helpful documentation on the site. It is just kind of assumed that the reader will figure out how totally pivotal the call signature of the ROLE is to future pluggability. The flip side is that the promise of COP is so insanely huge. This really is the holy grail, if it could be made to work for the average fellow. Source forge is full of very cool things that I would never think of trying, (for example), not because they wouldn't help me, but because of the horrible prospect of tight coupling. But give me a way to bring them in loosely coupled......without fear of pimping the rest of Avalon in the process, and...... The way I see it, Paul, Leo, Peter, Berin and Federico would publish in bold type a page for contributors that went like this: Want to contribute your Implementation or Component? 1. Design the interface per some very standard JBLAH or other API's 2. Submit the interface as a formal ROLE [stop, do not proceed beyond this point] 3. When approved, then and only then, write your component. 4. If you have non-standard public calls that your component requires, that is fine, but they need to be made in a separate ROLE so as not to pimp the rest of us who don't want to make them. 5. Submit your component. This would allow lesser brained individuals such as myself, a "See Dick Run" level of guidance. A simple roadmap to follow, as even I can follow simple rules. And I could then bring in my CalendarMaker component, or some other cool functionality which would otherwise be absurd for me to consider contributing. (not a real example). And no-one else would be pimped in the process, which is the most important part. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
