Yet Another PEP: Query Protocol Interface or __query__

[Clark C. Evans]

On Mon, 26 Mar 2001, Carlos Alberto Reis Ribeiro wrote:
> a) The proxy adapter is completely transparent to the object instance.
> b) The adapter maps only the methods that are mandatory by the protocol 
> specification. This leads to better encapsulation and abstraction (all 
> details of the object are hidden from the protocol user).
> c) Method names may be different in the object. The protocol does the name 
> translation.
> d) The protocol instance may point to methods in disparate objects, which 
> leads to a interesting type of 'composition'.

Right.  I think this complements what I was proposing nicely;
and could be built-in as a way for adapter/proxy to be built.

> Hummm... I see your point. My intention is different - avoid mixing 
> 'protocols' and 'class definitions'. One of the reasons was the potential 
> for name clashes, as shown in my example. A protocol does not need to be 
> represented *exclusively* by a class in the hierarchy. A single class may 
> implement multiple protocols, but some protocols may need a composition of 
> objects to do the work. For example, a composite object may contain lots of 
> objects that gets exposed through interfaces in the container.
> 
> Also I see no reason to avoid defining some kind of 'simple' interfaces in 
> this PEP - in the end, protocols are better mapped to 'interfaces' than to 
> 'classes'. It's much more flexible in this way.

Yep.  I like your mechansim for supporting interface proxy's.

> class ProtocolSequence:
>    """ Protocol to implement sequence-like objects """
>    def __len__ (self): pass
>    def __getitem__(self, key): pass
>    def __setitem__(self, key, value): pass
>    def __delitem__(self, key): pass
> 
> In this example, ProtocolSequence is the specification of the methods used 
> for sequence type objects. Sequence objects does not need to be derived 
> from ProtocolSequence; they may be written from the scratch, or be derived 
> from UserList, etc. Again, keep in mind the potential of composition as a 
> technique to build large systems. It is important to avoid the assumption 
> that inheritance is *the only way* to build OO systems.

In this respect, what you are proposing is very much aligned
to what the interface proposals out there try to do, i'd hazard
to say this is the "bridge" between the two proposals.  No?

Best,

;) Clark