> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> It is so funny to see one arguing for exceptions in one
> place, then against them in another (and vice versa).
>
Throwing Exceptions for exceptional circumstances?
> > > > Also, with just String hints, if you use a ServletRequest
> > > as hint, you
> > > > end up with:
> > > >
> > > > lookup (role, stringifyRequest (request))
> > >
> > > yes. Keeping the interface more simple/limited means that
> > > complex use of the interface becomes more complex. This is a
> > > choice; I'm all for keeping the CM simple. For complex uses,
> > > there's JNDI, DAP, etc etc.
> >
> > I'm against it. If the framework is intended to make writing of
> > containers easy - then I'd be with you. But when you can
> get complex
> > use by the client as cheaply as this, then I think it makes
> sense to
> > put it in. Complexity should, when possible, be moved from
> the client
> > and into the framework - after all, using the framework to
> reduce the
> > complexity in our own code is what this is all about, right?
>
> good point. But still
>
> lookupFunction( String e, Object key ) seems too complex. It
> doesn't resemble a Map enough. What is it internally,
> conceptually? A two-dimensional hash? Why does a directory
> need a two-dimensional hash? I can see one-dimensional, and
> n-dimensional. I don't get the two-dimensional.
It's not 2D - it is n-D. The Object may be anything - a Map or
whatever. The reason I want String,Object is because we have
fixed one dimension to be an interface name. If we hadn't,
a lookup(Object) would do.
> > > Which of these is most desirable, when that which you are
> > > looking up is _not_ guaranteed to exist?
> >
> > The exist() way of doing things. But the overwhelming use
> case is for
> > composers to directly call lookup() for components they *need* as
> > opposed to components that are optional - in which case they use if
> > (hasComponent()) lookup(). And thus the Exception way of
> doing things
> > is better.
>
> Uh, I'm thinking the reverse: the overwhelming use case is
> for composer to call lookup() for components they need, so
> they specify to the container that these are required and the
> container guarantees they're there or doesn't call compose()
> - so they do *not* use exists() there. Where the component
> can be optionally present, its existence is not guaranteed by
> contract.
That's what I meant, but maybe not what I wrote.
> > > if the lookup should never fail, neither if(exists()) nor
> > > try{}/catch{}/finally{} should be necessary at all.
> >
> > *should* as opposed to *could*! A lookup failing is an exceptional
> > case, and should be treated as such.
>
> But when the container guarantees "if you configure me
> correctly, the lookup will never fail", why should the
> component developer still check?
Because you get an instant ComponentException instead of a
NullPointerException later in the processing.
> > Since you are removing functionality from the CM, I want to know
> > whether you are removing it from the system completely, or if an
> > equivalent to release() will exist, just in another form.
>
> I thought we'd keep these issues separate (and separate
> proposals), as that is what they should be.
No. If you want to replace something that does A, B and C,
with something that only does A and B, you have to explain
how to do C or how you solve the problem that C was intended to
solve.
And you don't. Peter doesn't, and Berin doesn't either. Just a fond
hope that it is possible - but is it really, under the constraints
imposed by your proposed interface?
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
