Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^4: Use method/function signatures with Perl

by Ovid (Cardinal)
on Dec 06, 2004 at 16:03 UTC ( #412677=note: print w/ replies, xml ) Need Help??


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

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?

Cheers,
Ovid

New address of my CGI Course.


Comment on Re^4: Use method/function signatures with Perl
Re^5: Use method/function signatures with Perl
by dragonchild (Archbishop) on Dec 06, 2004 at 16:16 UTC
    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.

    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.

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

      Cheers,
      Ovid

      New address of my CGI Course.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://412677]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (9)
As of 2014-08-30 15:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls