[Python-Dev] Re: PEP 246, Object Adaptation (was Re: Single- vs. Multi-pass iterability)
Clark C . Evans
cce@clarkevans.com
Mon, 15 Jul 2002 11:58:37 -0400
On Mon, Jul 15, 2002 at 10:22:25AM -0400, Aahz wrote:
| in fact, it suffers from the obverse problem. Consider this:
|
| class C:
| def open(self, name, flags=None):
| def read(self):
| def write(self, value):
| def close(self):
|
| Can instances of C be used where a file object is expected?
>From the "Object Adaptation" perspective, you would have a file
protocol (perhaps the built-in File object works). And then
you could call "check()" or "adapt()" built-in functions.
check() at a high level, this built-in function first asks
the object iself directly: "Hey are you a File?"
if the response is affirmative or negative, then the
search is done. If the object doesn't respond (either
it lacks __check or __check returns None) then the
built-in then goes and asks the protocol object if the
file complies. When all else fails, the built-in
could use some default logic of its own.
adapt() returns the object itself if check() is true; otherwise
it asks the object and then the protocol to provide
a wrapper. If neither provide the wrapper, then an
error is thrown.
The key thing about the Object Adaptation proposal is that it
leaves wide open what it means to comply. This flexibility is
necessary since the methods for determining compliance may vary
from situation to situation; no size fits all. With this proposal,
both the Object and the Protocol can use what ever methods are at
their disposal to gauge compliance and/or create an adaptative wrapper.
That said, what built-in compliance systems Python may choose to
integrate into the core system are othogonal; or optionally, Python
could have multiple complance mechanism; Eiffelish contract based
mechanism for those who are in that school of thought, or a "type-safe"
interface based complance for those who think this is the best approach.
This proposal leaves all of those options open and favors no-one.
So, I'm sorry if I diverted this into "Are interfaces good or bad".
Clearly the idea of a protocol is good, interfaces are OK, but I have
my doubts about them being good enough ballence between power and
complexity. It's nice to see a simple yet powerful mechanism like
this being considered... thanks!
Best,
Clark