duck-type-checking?

[Joe Strout]

On Nov 12, 2008, at 2:42 PM, Tim Rowe wrote:

> And then the original class definition changes -- new members added --
> but the ones from the factory class don't change, and so are no longer
> compliant with the the factory class (which doesn't support the new
> "form_pun_relating_to_avoiding_a_high_hazard()" method) .

Yes, that's certainly a risk.  But I'd rather risk something that  
breaks the code in an obvious way during development, than risk  
something that breaks it in a subtle way and is more likely to be  
discovered by the end-user.

> Fine. If you checked for all the members of the class that your code  
> uses, it makes
> no difference. ABCs give you a way of doing this, but in their absence
> it's a long list of checks.

True.  I love the ABC approach; now I just have to figure out whether  
I love it enough to move our entire company over to 2.6 (despite 2.5's  
great advantage that it's pre-installed on every Mac by default), or  
whether instead I'll come up with some sort of ABC-compatible interim  
solution I can use to hobble along until we do switch.

> If you /can/ use inheritance then it saves having to do those checks.

Well, sure.  And any sensible checking system would first check  
isinstance and issubclass before painfully checking each of the  
methods and properties in the declared interface (or ABC), for  
performance reasons at the very least.

But the point is to have a system that will easily and efficiently  
handle the common cases, while still being able to handle the uncommon  
ones.

Best,
- Joe