469,365 Members | 1,749 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,365 developers. It's quick & easy.

Re: duck-type-checking?

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

Nov 12 '08 #1
1 2158
Joe Strout wrote:
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.
Seems to me that putting in these kinds of assertions isn't
going to make much difference to the proportion of bugs that
slip through testing.

Your test suite still has to be comprehensive enough to
trigger the assignment of the erroneous object. If it's
not, your assertions won't catch anything. If it is, then
you would have found out during testing in any case.
It might be more difficult to *fix* the problem without
the assertions, but you will still catch it.

--
Greg
Nov 13 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by srijit | last post: by
6 posts views Thread by Steven D'Aprano | last post: by
reply views Thread by Peter Larsen | last post: by
6 posts views Thread by Daniel Santa Cruz | last post: by
15 posts views Thread by atbusbook | last post: by
1 post views Thread by Luis Zarrabeitia | last post: by
reply views Thread by Neville Dempsey | last post: by
reply views Thread by Neville Dempsey | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.