[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