Re: Re: Re: High level thoughts

Paul Prescod <[email protected]>:

> Let's say you have an object and you need it to conform to the "iterator 
> protocol". You call obj.iter().
> 
> Let's say you have an object and you need it to conform to the "string 
> protocol". You call obj.str().
> 
> But this doesn't scale. What if you have an object and you need it to 
> conform to the "file protocol." Are you going to add "obj.file()"?

I think the whole concept of having an infinitely extensible set of
"protocols" that anyone can add to doesn't scale well in the first
place.

Experiences I've had in getting C libraries from different sources to
work together has led me to the view that the best way to ensure
interoperability between components is to design them to use nothing
but bog-standard, language-defined data types and structures when
interfacing with the outside world.

In Python terms, that means sticking to the basic, well-known
protocols -- number, sequence, mapping, iterator, file, etc.  If it
makes sense for your type to be seen as one of these, define the
appropriate methods. If it doesn't, adapting it wouldn't be possible
anyway.

In short, I don't really see much practical use for an elaborate
protocol adaptation framework.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
[email protected]	   +--------------------------------------+