> 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.
I agree.
While I don't have a huge aversion to suffixing classes with "2", I would
rather see a name which recognizes and identifies our need for change.
I liked Gerhard's mentioned options of:
1. GenericComponentManager
2. GenericComposable
I would add perhaps:
1. ExtendedComponentManager
2. ExtendedComposable
I can't help but suggest PointyHairedComponentManager as well. :-)
--lar
> -----Original Message-----
> From: Paul Hammant [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, February 10, 2002 11:18 AM
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
