Yet Another PEP: Query Protocol Interface or __query__
aleaxit at yahoo.com
Wed Mar 21 01:04:43 CET 2001
"Clark C. Evans" <cce at clarkevans.com> wrote in message
news:Pine.LNX.4.21.0103201837570.21343-100000 at clarkevans.com...
> Please have a look at the PEP below, it is intended to be a
> light-weight solution to "typing" based on programmer intent.
At least when read at 1 AM -- sounds cool. Further, the
builtin query function could support _adding interfaces to
an object post-facto, non-invasively_, much like the
'typeclass'-based ideas that were floating in my mind
recently and surfaced in some of my recent posts. I.e.,
the query() builtin would both try getting the interface
from the _object_, by passing that interface to the obj's
query method, AND also try doing it the other way
'round -- asking the interface if it knows how to wrap
the object so it (the interface) gets implemented. That
would require interface-identifiers to be richer objects
than just string, or a registry which associates a string
identifying an interface with such a richer object.
I fully agree (as a COM expert) that COM's identity rules
are not appropriate as the semantics of query(). Indeed,
COM defines an alternate approach to getting an
interface providing a service (the IServiceProvider
interface) for the specific purpose of uncoupling the
identity of the object providing the service from that
of the object being queried for it -- it's OK if the same
object does both, but not a requirement. Particularly if
we accept the idea that the query built-in can query
both the object AND the interface, this decoupling seems
the right semantics for this case.
Since 'interface' is so deucedly overloaded a word, maybe
'protocol' might be be better -- so we only get confused
with FTP, HTTP and the like:-).
More information about the Python-list