in reply to Re^4: Use method/function signatures with Perl
in thread Use method/function signatures with Perl

Let's say I have a subroutine defined as 
sub foo (ARRAY $arr) { ... }

[download]

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

package Bar;

sub new { bless [], shift }

[download]

This means that 

my $bar = Bar->new;

foo( $bar );

[download]

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";
    }
}

[download]

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

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^6: Use method/function signatures with Perl
by Ovid (Cardinal) on Dec 06, 2004 at 16:35 UTC

    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);

    [download]

    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];
}

    [download]

    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) {...}

    [download]

    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.)

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]
[d/l]
[select]
      That breaks immediately because &foo is expecting an ARRAY, not an object of class Bar.

      In other words, because you're (mis)using ref (which we agreed you shouldn't), you already implement the scheme I suggested. However, there's going to be the user (and it's usually someone like me ... :-) that would assume that since I'm using an array to represent my Bar class, it should fit into either an ARRAY or Bar hole.

      It may not be a code issue as much as a documentation issue. That said, there is still an issue. :-)

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

In Section Meditations