Yet Another PEP: Query Protocol Interface or __query__

[Carlos Ribeiro]

Disclaimer: It's 1 AM and I'm running on brainstorm mode. Please ignore any 
dumb idea and trash accordingly <wink>

At 18:43 20/03/01 -0500, you wrote:
>     A new built-in method, __query__ is proposed.  This method has
>     a single argument, an interface protocol identifier, and either
>     returns an object supporting the given protocol, or throws an
>     unknown exception.

Do you want __query__ to act as a class factory? In your example you return 
"self" in one of the cases, and a new object instance in the other. Anyway 
I dont see the need to do it this way in Python. There is some confusion 
going into returning an object - which is an instance of a class, right? - 
and returning an interface. It is not the same in COM, but maybe it could 
be the same in Python. (It's 1 AM, so maybe I get it better tomorrow).

Of course, there's always the question of supporting multiple interfaces 
with name clashes and so on. I dont see any way to do it without resorting 
to some magic. For instance, __query__ could return an object supporting 
only the methods specified on the given interface, but pointing otherwise 
to the same attributes. The methods would then be mapped to the ones 
implemented in the object instance.

Very Simple Example (please ignore any dumb syntax mistakes :-):

class MyClass:
   def __myrepr__(self):
     pass
   def __query__(self, protocol):
     # supports enumeration methods with the default names
     if protocol == "org.python.enumeration":
       return self
     # it has a __repr__ compatible method with other name
     elif protocol == "org.python.printable":
       # we will hack the object representation
       printable_interface = self
       printable_interface.__repr__ = self.__myrepr__
       return printable_interface

Ok, this is a very simple example, and I know it's wrong. It has side 
effects - mainly, 'self' and 'printable_interface' are pointing to the same 
object instance :-) It would work for some particular cases (such as this 
one). However, the generalization would be much more complex than this. We 
would need to have an "almost exact" copy of the original object, only that 
the methods table would be different. I really dont know if this would be 
possible.

>     An interface protocol identifier is a lower-case string having
>     a reverse DNS host name string:   TLD '.' DOMAIN ['.' NAME ]*
>     Where TLD is a top level domain such as 'com' or 'uk.co'.  DOMAIN
>     is a registered name in the given TLD.  And one or more optional
>     NAME separated by a period.  NAME is a sequence of one or more
>     alphabetic characters including the dash '-' character.  See the
>     relevant ITEF specifications for specific details.

Why not use a XML DTD-like syntax? That would allow the use of XML to 
express the interface definition in some way. The interface definition 
could even include some information about expected parameter types, without 
having to change Python type(less) model.



Carlos Ribeiro


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com