[Types-sig] QueryProtocol
Clark C. Evans
cce@clarkevans.com
Fri, 23 Mar 2001 03:26:38 -0500 (EST)
On Tue, 20 Mar 2001, Michel Pelletier wrote:
> The way I understand the proposal, you query some interface
> for an object that implements an well known interface.
In the recent proposal, wrongly or not, I've been calling
the 'thing requested the protocol. As it stands a protocol
can either be a class or a type, and with your interface
type it could also be an interface.
I never really addressed the following, my apologies.
> o Where does the initial query interface come from?
> o Does a registry need to be kept (probably)?
The above two problems occur when ever the factory
pattern is used. Note that creating a python object
has both of these questions... the answer to the
first question is "it comes when you start the
python interpreter" and the answer to the second
question is "yes, this is your python path and
the packages (directories) and modules (files)
found within this path".
> o What if multiple object implement the same interface?
This question is a "no problem" with almost every
class/interface system I know of. For instance,
Microsoft's IWebBrowser interface has a Mozilla
implementation. No problem here.
...
The proposal that I put forth is similar, it is an
"adapter factory". That has two parts:
a) if the object already implements the protocol
(type, class, or interface if approved), then
there is no problem, and the object is returned.
b) otherwise, the class is given a chance to
assert that the object does indeed comply with
the protocol, and may be allowed (can_wrap)
to provide a wrapper object if this
compliance can only be indirect.
If an "interface" proposal, or some way to add
Paul Prescod's __check__ method is found, then,
the proposal makes it clear that one more
method may be added to this factory:
c) otherwise, the protocol (class or interface)
is given a chance to assert that the object
does indeed comply with the protocol and
if not, my be allowed (can_wrap) to provide
a wrapper object.
Paul mentioned a while back that an adapter registry
may also be useful... so, the factory could then
be extended to add the last method (that I can
think of):
d) otherwise, if the context/environment is given
a chance to assert that the object does indeed
comply wth the protocol, and if not provide
a wrapper object...
Right now, to keep the proposal simple, only
methods (a) and (b) are introduced; although
a seperate and smaller PEP could be created
to add (c) to the adapter factory.
...
Does this help? This proposal is a far cry
from Microsoft's CreateObject call, which you
seem to be picking apart.
Kind Regards,
Clark