[Types-sig] QueryProtocol

[Marcin 'Qrczak' Kowalczyk]

Fri, 23 Mar 2001 02:09:49 -0500 (EST), Clark C. Evans <cce@clarkevans.com=
> pisze:

> As I understand it, the list of interfaces which a class implements
> would be stored by the class (this is the declare case above).
> I think Marcin was suggesting the opposite... that the list of
> Classes which support the Interface could be stored with the
> Interface. Is this right Marcin?

Yes.

Note that this is a common technique, but not a formal requirement.
An interface may choose to check in another way. Checking is a method
of the interface, and all methods in Python are "virtual" in C++
terms, so there is no need to require them to be implemented in the
same way. The list is an implementation detail of the interface,
if present at all.

> Now, for "adapting" a class to an interface, having both methods is
> critical.  You want the class to be able to wrap itself to comply
> with particular interfaces; but also, if interfaces get added,
> you may want them to allow the class to be wrapped.

It's not critical: either approach emulate the other (in cases we are
talking about). An interface provides a method to bless new classes.

> Testing is certainly useful, but I think testing is different than
> what Marcin is talking about.  I think he is just talking about
> Signature testing, yes?

Not quite. More a specification of the signature rather than testing.
It needs not to be the primary thing which is being tested. We can
trust whoever makes the registration. Perhaps only assert that methods
which are needed to implement the interface are in fact present.

It's still not clear for me what is the best way to:

1. Provide the functionality needed to apply an interface. It should
   be somewhow passed during the registration. Since it will often be
   a bunch of named functions, syntax support would be helpful.

2. Get the functionality provided by an interface from the interface
   and a conforming object. Haskell's emulation would suggest that the
   interface is - or can produce, but it's handier when it already is -
   an object which contains appropriate functions as attributes, which
   recognize types of their arguments and dispatch on them.
  =20
   In this way we don't need to separately pass kind-of-self to the
   function derived from an interface (first to dispatch, next to
   act on), nor to build "bound methods" which have been dispatched
   and hide the object to be acted on in themselves, waiting only
   for the remaining arguments, and we get multiple dispatch for free.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK