in reply to if (ref $value eq "ARRAY") {

But, I got to thinking. What if it's not really an array, but a class that looks like an array, or a tie? Should I use isa instead?

One of the downsides of a weekly-typed language is that you have to jump through lots of hoops if you want to protect yourself from every concievable ill that clients of your APIs can heap upon you.

So, how much testing should one do to see if arguments are what are expected, and how does "overloading" functions to understand different data types complicate matters?

Do as much testing as you need to, though if you find yourself using isa a lot, that's an indication that your interfaces need further thinking. A technique from Smalltalk, which I've seen used a bit in Java, is "double dispatch". It's a technique that, in part, lets you contain a geometric explosion in type testing when you introduce new types of objects. Look it up and study it. Double dispatch can be done in Perl.

Replies are listed 'Best First'.
Re: Re: if (ref $value eq "ARRAY") {
by John M. Dlugosz (Monsignor) on Aug 23, 2002 at 03:16 UTC
    I think some weakly-typed languages do better. To reflect back on the big thread from the other day that all languages evolve toward Lisp, Common Lisp allows for "overloading" functions based on type or arbitrary tests. So, one could separate things out into broad different things, but still be flexible within each thing.

    I guess that's just syntactic sugar around the test I could write inside the function, now.

    I think the concept here is that "all differences in allowed parameter types should be done through polymorphism". In Perl, that's hard to do with anything that's not blessed.

    But, it does suggest something. I could have an abstract base class to serve as an "interface", and recognise that case as well as the built-in things (plain scalar and array ref). Then, anyone wanting to pass an object and have it mean something to this function would simply need to make it "isa" that interface class.

    — John