[Python-Dev] Re: PEP 246, Object Adaptation (was Re: Single- vs. Multi-pass iterability)

[Clark C . Evans]

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