[Types-sig] QueryProtocol

Clark C. Evans cce@clarkevans.com
Fri, 23 Mar 2001 03:26:38 -0500 (EST)

On Tue, 20 Mar 2001, Michel Pelletier wrote:
> The way I understand the proposal, you query some interface
> for an object that implements an well known interface.

In the recent proposal, wrongly or not, I've been calling
the 'thing requested the protocol.  As it stands a protocol
can either be a class or a type, and with your interface
type it could also be an interface.  

I never really addressed the following, my apologies.

>   o Where does the initial query interface come from?
>   o Does a registry need to be kept (probably)?

The above two problems occur when ever the factory
pattern is used.  Note that creating a python object
has both of these questions... the answer to the 
first question is "it comes when you start the 
python interpreter" and the answer to the second
question is "yes, this is your python path and
the packages (directories) and modules (files)
found within this path".

>   o What if multiple object implement the same interface?

This question is a "no problem" with almost every 
class/interface system I know of.  For instance, 
Microsoft's IWebBrowser interface has a Mozilla 
implementation.  No problem here.  


The proposal that I put forth is similar, it is an
"adapter factory".  That has two parts:

   a) if the object already implements the protocol
      (type, class, or interface if approved), then
      there is no problem, and the object is returned.
   b) otherwise, the class is given a chance to 
      assert that the object does indeed comply with
      the protocol, and may be allowed (can_wrap)
      to provide a wrapper object if this 
      compliance can only be indirect.

If an "interface" proposal, or some way to add
Paul Prescod's __check__ method is found, then,
the proposal makes it clear that one more
method may be added to this factory:

   c) otherwise, the protocol (class or interface)
      is given a chance to assert that the object
      does indeed comply with the protocol and
      if not, my be allowed (can_wrap) to provide
      a wrapper object.

Paul mentioned a while back that an adapter registry
may also be useful... so, the factory could then
be extended to add the last method (that I can 
think of):

   d) otherwise, if the context/environment is given
      a chance to assert that the object does indeed
      comply wth the protocol, and if not provide
      a wrapper object...

Right now, to keep the proposal simple, only 
methods (a) and (b) are introduced; although
a seperate and smaller PEP could be created
to add (c) to the adapter factory.


Does this help?  This proposal is a far cry
from Microsoft's CreateObject call, which you
seem to be picking apart.

Kind Regards,