[Types-sig] QueryProtocol

[Clark C. Evans]

These two quotes are the most interesting to me:

 "The deep(er) part is whether the object passed in thinks of
  itself as implementing the Foo interface. This means that
  its author has (presumably) spent at least a little time
  about the invariants that a Foo should obey." -- Guido

and
 
 "There is no concept of asking an object which interface it
  implements. There is no "the" interface it implements. It's
  not even a set of interfaces, because the object doesn't 
  know them in advance. Interfaces can be defined after objects
  conforming to them are created." -- Marcin 'Qrczak' Kowalczyk 

Mostly beacuse I see them as complements.  Indeed, this distinction
between "declarative, I am a such-and-such" vs "descriptive, It 
looks like a such-and-such"  are at the basis of Paul's proposal, 
with two type check methods.  

Further, there was question about the difference between
the words "interface" and "protocol".  I may be incorrect, but
I'd like to align "protocol" with Guido's vision of types and
"interface' with Marcin's vision of types.  Thus, the only
way to know if an interface is correct, is to brutally check
it (not trusting the prorammer).  However, one cannot check 
the protocol easily... thus, this falls more into the realm
of intent.  

With these points in mind, I share Samuele Pedroni reservation 
about mixing these methods (and blurring protocol with interface)
and I have two suggestions:

(a)  It may be prudent to adopt Marcin's view for 
     an "interface type-checker" and only support the 
     descriptive method for the PEP Prescod is preparing.
     The declarative check may not be sufficient (or even 
     accurate based on Python's dynamic nature).  Having 
     both methods is perhaps confusing as Samuele asserts.

(b)  Introduce a new, complementary method for the declarative
     method.  Thus, making a second PEP which is concerned
     about "protocol declarations" and not about "interface 
     checking".

Perhaps I'm completely wrong here, this is just my gut reaction
to reading the first 168 posts on this list.

...

I picture a "protocol declaration" as a dynamic discovery
mechanism much like Microsoft COM QueryInterface.  However,
I think there is an important distinction as python does
not have strict typing -- so I'm calling it QueryProtocol.  

For example, let's say I'm traversing a tree-like structure
and I want to make some generic algorithems that do this
sort of thing.  I can label my protocol, "com.clarkevans.treenode"
and then ask any object passed to my algorithem:

 node = obj.queryprotocol("com.clarkevans.treenode")

And it will return to me an object (perhaps itself) which 
has the type of behavior that I expect.  Note, unless the
object *explicitly* supports the com.clarkevans.treenode
protocol, this call will fail.  This is declarative.

...

As another example, if __queryprotocol__ was a built-in, with 
a protcol(object,"my.protocol") function, then the __iter__  
slot of the iterator PEP could be done away with, as
__iter__() would be the same as __queryprotocol__("org.python.iterator")

...

Summary: 

 Perhaps I'm wrong here, but I think there are two
 different kinds of "type" being tossed around 
 here, that of a protocol (which is all about
 behavior and expectations) and interface (which
 is about function signatures).  Protocols are
 best supported via declaration and discovery, 
 while Interfaces are best checked via descriptive 
 techniques.

 The declarative, protcol method can be implemented
 through a simple "query" interface.

Clark

P.S.  QueryProtocol is _not_ the same as coersion!