Stephen, I'm not so sure. We're trying to sell Component assembly, component orientated programming. With the proposal with Service as the replacement word, we've duplicated an entire package. I thought wholescale class cloning was no-no, even at tool level.
We have three choices: 1) Brave replacement of Component with Object return type on lookup(..). Pros: small change Cons: Not backwards compatible - lots of recompilation and possible casting needed for users of API 2) Package clone (as per proposal booked in). Pros: backwards compatible. Cons: Overkill duplication, confusion. 3) "2" suffixed interfaces Pros: new new package, backwards compatible. Smaller amount of changes. Cons: "ugly" digit suffix to interface names. I think (3) is a front runner. For (2) the "medicine is worse than the cure". (1) I would do for selfish reasons, but we'd upset various communities, possibly to the point of mutiny. However, I am not active in maint of framework. I will leave the decision to others, but state that my highest concern is a timeline. I will vote..... if (1) is vetoed I'll vote for (3) over (2) and I really believe that loading a gun and shooting a package to avoid a "2" suffix is over the top. - Paul >Paul: > >I don't agree with point concerning the absence of the >word "Component" - a component is an abstract thing - more >abstract than the computational descriptions we can put >into Java interfaces. In fact I think the absence of the >word component in the interface name clarifies (for me) the >function from a computational perspective as distinct from >the role of the interface in the overall component >abstraction. > >Its Sunday afternoon and there are just too many big word >in that paragraph - time I had another glass of wine! > >Cheers, Steve. > > >>-----Original Message----- >>From: Paul Hammant [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, 10 February, 2002 14:25 >>To: Avalon Developers List >>Subject: Re: ComponentManager interface >> >> >>Peter, >> >>>>Composable2, ComponentManager2 ? >>>> >>>ewww - runaway, runaway ;) >>> >>I knew we we going round in circles dude.... You're the one pushing >>for 'Component becomes Object' (by implication) then backing away ;-) >> >>I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it >>is perfect but for the absense of the word "Component". >> >>We are not without precident, all these from JDK1.4 : >> >> LayoutManager2 >> GlyphPainter2 >> Parser2 (Crimson) >> ElementNode2 >> NamespaceSupport2 >> >><fx> ducks from Peter's bullets </fx> >> >>Packages Evolve. Lets understand that. We have no versioning built >>into Java in the sense that two versions of the same API could >>interoperate in the same classloader/classpath. In ten years time we >>will have loads of dead packages (java.io is example) or loads of >>suffixed classes/interfaces. We could migrate all functionality >>immediately to the "2" versions and for the original versions have a >>hand crafted proxy that routes all calls through to the new one. >> >>It is one strategy that will be taken with AWT in the end I guess. >> Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs >>own heavyweight comps. Sun could obsolete AWT and or have a near enough >>pure Java "AWT2" that AWT routes through to. In fact AWT could route >>through to Swing, more or less completely hiding the experience. In >>that version of the graphic toolkit all Swing would need from the >>iunderlying OS would be mouse, kbd and "rectangle reservation" graphics >>support. Swing could sit small OSs that have no advanced graphics API. >> Sigh... Java's original Component model ;-) >> >>- Paul >> >> >> >>-- >>To unsubscribe, e-mail: >> ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
