[Types-sig] Interfaces API: a concrete contact point: more subtlities

Samuele Pedroni Samuele Pedroni <pedroni@inf.ethz.ch>
Fri, 16 Mar 2001 13:21:22 +0100 (MET)


Hi. Sorry for insisting <wink>

Paul Prescod wrote:
> 
> Samuele Pedroni wrote:
> > 
> > Hi.
> > 
> > If we  really aim for having just interfaces (still not convinced about
> > that <wink>)  IMHO a possible solution is to define their check this way:
> > 
> > if the input to check against an interface IFace is an instance foo, we
> > check if foo has an '__implements__'
> > attribute in that case we test IFace.isImplementedBy(foo), otherwise we
> > check if foo has all the required signatures :).
> 
> That's exactly what my code already implements:
I intended something slightly different.

(A)
> 
>     # if the object CLAIMS to support an interface, we believe it
>      if _findInterface(val, iface):
>         return 1    
Namely:
       if hasattr(val,'__interfaces__'): # or Michel Pelletier __implements__
         return _findInterface(val,iface)
       else:
         ...

So to say to be on the safe side. 
Clearly if one want to have something which implements for example __getitem__
 and some "true" interfaces, he will have to declare expliclitly
ISequence too:

class A implements IFoo,IBat,ISequence:
 ...
 def __getitem__(self,ind):
  ...

Not that nice ;).

(B)
> 
>     # if the object LOOKS like it supports an interface,  good 'nuff
>     else:
>         return iface.__check__(val)
> 

Clarifying this I'm more conviced about my initial opinion that this merging
is just confusing:

(A) is the right kind of "type checking" for the
 for-runtime-reflection-&-eventually-for-design-decisions-enforcing
 interfaces of Michel Pelletier proposal, which (I imagine) will
 carry a lot of implicit requirements
 
(B) express the plain-old python approach to protocols, it is mostly
 needed for "type checking" the std lib, and the checked things
 would be special __foo__ methods or having simple things like a 'read'
 or 'readline', but checking anything too much complex this way is expensive
 and does not make (IMHO) that much sense.
 
I repeat sometimes one would prefer doing "type checking" for an interface
as in (A), sometimes like in (B) (especially for the std lib), they
are different approaches, and there may be a need to distinguish them
and spell this out.

OTOH: for defining protocols ("interfaces") for the (B)-kind of test
the full featured interface syntax is not really necessary:
mostly they will be predefined (the common protocols: sequence etc)
or expressed through somekind of anonymous protocol/interface/domain
construction (as proposed by Tim Hochberg).

regards, Samuele Pedroni