[Types-sig] QueryProtocol

Clark C. Evans cce@clarkevans.com
Tue, 20 Mar 2001 22:46:25 -0500 (EST)


Paul, 

Thank you for your feedback.

> "Clark C. Evans" wrote:
> >     A new built-in method, __query__ is proposed.  This method has
> >     a single argument, an interface protocol identifier, and either
> >     returns an object supporting the given protocol, or throws an
> >     unknown exception.
> 
> What do you mean by "unknown exception". "UnknownInterface" exception?

I was vague here beacuse I didn't know what to do.
Perhaps "None" should be returned?

> >     An interface protocol identifier is a lower-case string having
> >     a reverse DNS host name string:   
> 
> Why a string? What if we let an interface be any object and we used
> object identity to compare them? That way we don't have to introduce a
> new namespace into Python. I have never seen a reverse-DNS string in a
> Python program and I am leery of adding the concept.

Ok.   This can be changed to "any object".  It would 
definately simplify the PEP.

> Maybe we will standardize the structure of interface objects and maybe
> we won't. Maybe we will standardize them some time in the future. I
> think that the addressing mechanism should be the Python namespace and
> not the reverse domain namespace.

I'm just weary about coupling this proposal with 
one that requires an interface object.

> >     In addition, a built-in query method could be introduced that
> >     calls the __query__ method on a given object.
> 
> You mean "query function."

How about "query object" 

> >     The iterator special interest group is proposing a new built-in
> >     called "__iter__", which could be replaced with __query__ and
> >     a blessed interface protocol identifier of "enumerator".
> >     Therefore calls to  obj.__iter__() could be replaced with
> >     obj.__query__("enumerator") with no semantic difference.
> 
> I don't know much about __iter__ but my first instinct is to be careful
> there. When you return an interface, you are semantically returning a
> view into the object. When you return an iterator, you are semantically
> returning another object that happens to have special knowledge of the
> first. In other words, interfaces should have no state. Iterators are
> *all* state. :)

An iterator is a "view" of a particular object.  The state
the view must maintain depends upon the requirements.
I don't see any semantic difficulty here at all.

Clark