> 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]>
