Leo, There is no need to be so faceteous.
- Paul > >>From: Stephen McConnell [mailto:[EMAIL PROTECTED]] >> >>Leo: >> >>>And then you can use om.lookup for objects and components. >>>Does this solve your immediate needs? That is, getting >>>something working NOW, with not too much crap for future >>>cleanups? >>> >>Absolutely not!!!!! >> > >Stephen, > >well, you were not asked. Whether this fits with your idea of what should be >is utterly irrelevant. > >Paul needs something ***now*** as in "right this second". > >I have the impression that his development is ***blocked*** until he can >get non-Component classes out of a CM. If I am wrong, well - ignore the >solution and we'll hack away at the next-generation CM. > >I am very well aware that the solution I proposed is very temporary, >and not a substitute at all for a proper solution that will be in >Avalon 5. Or 4.2. Or whatever. > >But: > > - It allows him to proceed with his project ***NOW***. > - It allows him to do what he wants with Avalon 4 ***NOW***. > - It can easily be upgraded to Avalon 5, or whenever the new interfaces > become available. > >Whether it sucks in an architectural way is not even a consideration. > > ****** I know it does. ******** > >>Please go back and read the proposal. >>http://www.mail-archive.com/[email protected]/msg06099.html >> > >I am well aware of the proposal, and since I consider it madness to >expect the client to be aware of poolable/threadsafe I am -1 on it. > >The proposal, as given, is *more* than just a jettisoning of the Component >interface. If your proposal had just been "Component -> Object for >ServiceManager, >otherwise same contract as CM", I would have been +1 on it. But it is *much* >more. >It shifts responsibilities around in ways that I consider unacceptable. > >If SM replaces CM in Avalon5, *all* code written for Avalon4 will break. Not >just >in a way that can be solved with a search and replace, but the code has to >be >re-engineered to detect poolable components, or do away with those. > >>The solution is already there - you may want to sit around until >> >summertime > >>contemplating the meaning of life but some of us have more pressing >> >agendas. > >Stephen, I am well aware of pressing agendas. That is why I sent that >solution >to Paul. There is not enough time to get anything into Avalon proper. >The solution I gave is precisely for pressing agendas. If development >is blocked due to an API constraint, then a way must be found around that >constraint so development can proceed. Then, when the API has changed to >something that can be used without the kludges added before, remove kludges. > >THAT is what my solution to Paul is about. > >Every second, Paul & co. are basically idling. If they can get a kludge in >that allows them to proceed, is that not preferable to idling even if it >means that some changes will have to be made to the code afterwards - >changes that can easily be contained to a single abstract base class? > >/LS > > >-- >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]>
