[Types-sig] QueryProtocol

[Clark C. Evans]

On Thu, 22 Mar 2001, Michel Pelletier wrote:
> On Fri, 23 Mar 2001, Clark C. Evans wrote:
> > > It's more about not specifying interfaces at the point of a class
> > > definition than about the method of their specification and checking.
> >
> > Exactly, and this is what I was trying to convey:
> >
> >    declare     -> The class C declares: "I implement interface I".
> 
> That's cool.
> 
> >    descriptive -> The interface describes what it needs
> >                   for a class to be compliant.  Then, later
> >                   a checking mechanism (perhaps using the
> >                   Interface itself) looks at the description,
> >                   looks at the class and exclaims:
> >                   "Upon examination of the methods, attributes,
> >                    signature and other information available
> >                    regarding the class C, it does indeed
> >                    comply with the interface description."
> 
> Why does it actually have to *check* that much?  C is asserting I, so why
> don't you just trust it?  If you check all that every time, interfaces are
> going to be very expensive.

Let us address expense first.  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?  Perhaps some examination
may have to be done at the time a module is "imported",
but there need not be a run-time hit (just a load time hit).  

I think Marcin's point is very cool, however.  As one may
want to describe an interface *after* a large body of classes
already exist that implement it.  This is certainly 
interesting.   For instance, one may want to add a particular
abstraction where one didn't exist before.  In this case,
you can't afford to update every class with the new interface;
much like you can't afford to update each interface when
a new class is introduced.

For "checking" this is one thing, and IMHO, you could 
implement one or the other and they would both be useable.
However... I do think that a combination of *BOTH* methods
would be far more flexible.

...

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.  This is option 
(b) and (c) of the "checking and adapting" proposal.

The case where the class already "obviously" complies 
with the requested interface is case (a), and an 
external "wrapper registry" would be option (d).
The proposal I'm making is (a) and (b), with a clear
roadmap to add (c) for which ever Interface 
proposal gets accepted.

I hope this is clear...

> If you really want to *test* it, use a unit test.

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?  

;) Clark