Yet Another PEP: Query Protocol Interface or __query__

[Clark C. Evans]

On Mon, 26 Mar 2001, Carlos Ribeiro wrote:
> 1) What is a protocol? The simplest definition that I cant think of is: a 
> protocol is just a bunch of methods. An object is said to support a 
> protocol if it implements all methods of the protocol specification. The 
> specification defines the names and parameters of all methods.

This is what an interface is, and there is a proposal 
for this.  A protocol should be more broadly defined, no?

IMHO, the goal was to have this dialogue...

Hello protocol manager, do you know if this here
object supports the protocol Y?

  The protocol manager than says, "hang on a sec"
  and runs about doing stuff like this...

     Hello object X, do you support the protocol Y? 
       If yes, great, thank you!
       If no, can you make me a wrapper that does?
          If yes, great, thank you!
          If no, hmm, I'll go ask the protocol then.

     Hello protocol Y, is X compliant with your requirements?
       If yes, great, thank you!
       If no, can you make a wrapper for X that does?
          If yes, great, thank you!
          If no, well then... hmm.
  
     Perhaps the manager tries other methods (not implemented
     at this time, such as a registry)

   In any case, the manager goes back to the caller, and 
   says either:
     
     Hello Caller, here is an object Z that is compliant
     with the protocol, either it is the same object or a wrapper.

     Hello Caller, I've been unable to find a compliant
     version of this object for you... very sorry.
          
> 2) A 'protocol instance' is the minimal object instance that completely 
> supports the protocol.
> 
> 3) Now we're getting closer. My proposal is to have a method called 
> __adapt__ that returns a 'protocol instance'.
> 
> 4) So __adapt__ must convert a 'object instance' into a 'protocol 
> instance'. If the object implements the standard names with the default 
> names, this is pretty straighforward - the object could be used as a 
> protocol instance.
> 
> 5) The problem occurs when the object supports the protocol using methods 
> with different names. Assume that we have two different protocols asking 
> for methods with the same names, but with different semantics and/or 
> parameters. An object that supports both protocols will need some way to 
> map its internal methods to the ones defined by each protocol.
> 
> 6) We can solve (5) using a 'proxy', or 'adapter'.

Exactly.  The specific proposal, however, is a two-way (and perhaps
more than two way) lookup mechanism.  This is alot of legwork
to make for "smart" protocols. It shouldn't be automatic (like coersion)
but should be simple to use and extensible.
 
> EXAMPLE
> 
> Assume that we have these protocols:
> 
> a) protocol 'IntegerDivision'
>     supports the __div__() method for integer division
> b) protocol 'FloatDivision'
>     supports the __div__() method for floating point division

Hmm... This moves into Interface territory, I'd rather not go there.
I am *specifically* not defining what a protcol is!  That's why I
chose the nebulous word.  It's the bi-directional lookup mechanism
that is being proposed, no?

> 
> p.s. I think that it is possible to devise a highly optimized 
> implementation. In fact, if all protocols are known at compile time, this 
> should make it easier to optimize method calls, but this need to be 
> explored more carefully. This does not need to be made right now - as Clark 
> pointed out, may be it's better to see if people actually uses this.



> pp.ss. It was not my original intention, but we could use this mechanism, 
> as exposed in my example, as a way to implement the PEPs that propose 
> semantic changes on the numeric types.

Hmm.  This is more along the lines of what I'm thinking, 
not just method names.  Afterall, my "next()" may be 
completely different than yours.   What does yours do?
My "next()" replaces updates "self" so that it can be 
used to fetch information about the next object in a 
sequence, think Recordset.  Note, this is different from 
the upcoming iterator proposal, which has completely 
different semantics.

;) Clark