Hi Paulo:

> -----Original Message-----
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 18 February, 2002 17:57
> To: Avalon Developers List; Stephen McConnell
> Subject: RE: Son of ComponentManager
> 
> 
> Well, IMO either the CM (or OM) tracks the components or it 
> does not. 
> 
> Imagine that you start a project using a non-managed policy
> (no tokens) and than want to convert to a managed policy. If
> you have separated interfaces the compiler will help you 
> tracking all the stuff you have to change after you change 
> the type of the CM you are using, otherwise you are on your 
> own to search and replace all the stuff throughout the code.
> 
> Besides, this method
>   release(Object comp)
> as a different meaning for a managed CM than it as for a 
> non-managed CM:
>  - For a non-managed one it means "just release this 
>    component";
>  - For a managed one it means "release this component and
>    stop tracking it so you don't try to release it again
>    when I use the releaseAll(token)".

Agreed.

> Of course that you could also have a managed version like
>   release(Object token, Object comp)
> but then, it gets again more confusing and harder to use.

Yep.

> It is not that I think that EVERYTHING must be type safe 
> and hyper safe, but when there is an obvious way to make 
> things safer without too much cost...

My impression is that the question is comming down to cost.
I'm definately leaning on the conservative side bacause I 
know that components I'm developing will be plugged into 
serviceable objects that I know nothing about.  The tigher 
the contract at a compilation level the better bacause that
means more issues are trapped in develper space and less in
runtime (and runtime is much more costly).

> I only have a managed CM, 

ALmost the same case here - 95%/5% split.

> but if you really want both I 
> really thing that the best is to have both these 
> interfaces:
> 
>   public interface ComponentManager  // non-managed
>   {
>       Object lookup( String role );
>       Object lookup( String role, Object policy );
> 
>       void release( Object object );
>   }
> 
>   public interface ManagedComponentManager
>   {
>       Object lookup( Object token, String role );
>       Object lookup( Object token, String role, Object policy );
> 
>       void release( Object component );
>       void releaseAll( Object token );  
>   }
> 
> AND don't implement both in the same class!

Which is simple to enforce by changing the name from "lookup" to 
"release" :-) ... compile time enforcement.

> (I still miss the hasComponent() methods.)
> 
> As mentioned before, the reason for the
>   release( Object component );
> method is to free ASAP valuable/scarce resource, like 
> database connections and so.
> 
> 
> Does this make sense to you?

Yes it does.
Cheers, Steve.

> (I am coding too much these days and when this happens
> I become a much worse communicator.)
> 
> 
> Have fun,
> Paulo Gaspar
> 
> > -----Original Message-----
> > From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, February 18, 2002 7:34 AM
> > To: Avalon Developers List; [EMAIL PROTECTED]
> > Subject: RE: Son of ComponentManager
> > 
> > 
> > 
> > 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]>

Reply via email to