Re^3: Use method/function signatures with Perl

[dragonchild]

I used ref instead of Scalar::Util on the "simplest thing that could possibly work" principle. If you can give me a clear code snippet showing why ref is inferior (or point me to a resource.) I'll happily change it. (Update: Of course, I seem to recall some of the issues you mention. Hmm, I don't think I have a choice but to change it.)

Another question here - are you planning on allowing objects that happen to be implemented as ARRAY's in for ARRAY parameters? This will mean that your code is going to be ... complex, to say the least.

[Ovid]

I'm not sure I understand your question. My code doesn't actually care about the specific implementation. Can you give me an example of what you're thinking?

[dragonchild]

Let's say I have a subroutine defined as

sub foo (ARRAY $arr) { ... }

And, I have a class Bar. Today, it is defined as

package Bar;

sub new { bless [], shift }

This means that

my $bar = Bar->new;

foo( $bar );

will work just fine. But, what happens if the implementation of Bar changes from arrayref to hashref? This is a completely internal change, but one that will break the code listed above.

Personally, I would define it to be

if ($signature)
{
    if (blessed $x)
    {
        return TRUE if $x->isa( $signature );
    }
    elsif (ref $x)
    {
        return TRUE if ref $x eq $signature;
    }
    else
    {
        die "$x doesn't match $signature\n";
    }
}

In other words, if it's been blessed, you only consider the class - not the underlying implementation.

[Ovid]

Now I understand what you're asking. You're actually dealing with some interesting stuff here, but I think that most of the concern is a theoretical non-issue, but in practice it is an issue, but I think we're looking at it slightly differently. For example, your initial code doesn't work:

sub foo(ARRAY $bar) {...}

# later
foo(Bar->new);

That breaks immediately because &foo is expecting an ARRAY, not an object of class Bar. It's an easy fix:

sub foo(Bar $bar) {...}

Now it doesn't matter how someone implements Bar internally. However, there is one (false) objection and one very real objection. The false objection is this:

sub foo(Bar $bar) {
    print $bar->[3];
}

Obviously, violating encapsulation is going to cause problems regardless of whether or not method signatures are implemented. The real problem, however, and I think this is what you're getting at, lies in this:

my $parser = HTML::TokeParser->new(\$html);

sub foo(ARRAY $token) {...}

foo($parser->get_token) {...}

HTML::TokeParser returns array references. However, what if someone wants to use HTML::TokeParser::Simple? That module blesses the references. As a result, it is no longer a drop-in replacement. I am forced to alter the above code. (And this just highlighted a bug in my code that I'll have to fix ASAP -- darn.)