[Pdx-pm] interesting testing hole thats been dug

[Eric Wilhelm]

# from Michael G Schwern
# on Thursday 04 January 2007 11:20 am:

>Wil Cooley wrote:
>>  It obviously doesn't make sense to
>> require $obj->isa('Net::FTP'), because with duck-typing it doesn't
>> actually have to be a subclass.  How thoroughly should I test with
>> $obj->can() for the object's abilities?
>
>Your code already does all the checking it needs by calling methods on
> $obj.  About all ->can is going to buy you is a nicer error message,
> but then you have to keep a duplicate list of all the methods your
> code calls on $obj.  Its up to how lax or strict you want to be. 
> Since you're allowing duck-typing you're probably lax.

I agree that keeping a duplicate list of all of the methods isn't the 
way to go unless you can easily auto-generate it -- even then, it might 
be more strict than is actually needed.

I think there's usefullness in doing one check for 'get' or other 
similarly characteristic/indispensible method, just as a general early 
run-time sanity check (to be reasonably sure it's not a Shovel.pm 
object.)  Let the rest fail later with the 'Can't locate object method 
"foo"...' stock error.  This will make development easier, since the 
duck only needs to support what gets called on it in any given 
prototype/hack.

The exception would be when you're dealing with a set of classes that 
have agreed on some standard or convention (ala the USB spec's "what 
sort of device are you?" scheme -- but even olympus managed to botch 
that by only testing their "I'm a mass sortage device" camera against 
windows where the spec-mandated question never got asked.)

--Eric
-- 
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------