Paulo:
I agree with your point concerning the mixing of token and non-token methods in the same interface (at least methods with the same name). That was one of the reasons I attempted to separate out the token based methods using the "checkout" method name. I don't see any complication in dropping back to that. But can you confirm if that addresses the point your raising? Cheers, Steve. > -----Original Message----- > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > Sent: Monday, 18 February, 2002 00:44 > To: Avalon Developers List > Subject: RE: Son of ComponentManager > > > I already advised AGAINST using methods with-token and > without-token in the same interface. Did you notice that > posting? > > IMO it is VERY error prone. > > > Have fun, > Paulo Gaspar > > > -----Original Message----- > > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, February 17, 2002 6:26 PM > > To: Avalon Developers List > > Subject: RE: Son of ComponentManager > > > > > > > > > > > From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > > > > > Here is consolidation of the interfaces based on a logical > extrapolation > > > of the conclusions reached under this thread: > > > > > > interface Serviceable > > > { > > > public void service( ServiceManager manager ) throws > > > ServiceException; > > > } > > > > > > interface ServiceManager > > > { > > > Object lookup( String role ); > > > boolean hasService( String role ); > > > } > > > > > > interface ServiceSelector > > > { > > > Object select( Object policy ); > > > boolean isSelectable( Object policy ); > > > } > > > > > > interface ServiceResolver extends ServiceManager > > > { > > > Object lookup( String role, Object token ); > > > void release( Object object ); > > > void releaseAll( Object token ); > > > } > > > > > > interface PooledSelector extends ServiceSelector > > > { > > > Object select( Object token, Object policy ); > > > } > > > > > > Over to you. > > > > Got the correction: > > > > interface Resolvable { > > public void resolve( ServiceResolver resolver ) throws > > ExceptionThrownWhenLookupFails; > > } > > > > Where does the policy object in PooledSelector come from when a > lookup is > > done through a ServiceResolver? Isn't it necessary to have: > > > > interface ServiceResolver extends ServiceManager > > { > > Object lookup( String role ); > > Object lookup( Object token, String role ); > > > > Object lookup( String role, Object policy ); > > Object lookup( Object token, String role, Object policy ); > > > > void release( Object object ); > > void releaseAll( Object token ); > > } > > > > where the policy object is passed along to the selector if present? > > > > Before I go and vote for this one, I would also like to hear more > > about Peter's release-less version. If that one works, we could have: > > > > interface ServiceResolver extends ServiceManager > > { > > Object lookup( String role, Object policy ); > > } > > > > which is much cleaner. But it requires some other changes to the way we > > write > > components. See: > > > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2 > > > > and my response: > > > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2 > > > > /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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
