Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ferreira (5993)

ferreira
  (email not shown publicly)
http://www.ferreira.triang.net/

Just another Brazilian Perl hacker.

Journal of ferreira (5993)

Wednesday April 30, 2008
09:37 PM

Clashes between functional and OO worlds

[ #36294 ]

In refactoring some code, I opted for turning "warn/carp" calls into method calls "$self->carp". This way the objects could act by themselves (using CORE::warn/Carp::carp) or cooperate with others (via a closure).

sub carp {
    my $self = shift;
    my $on_warn = $self->on_warn;
    if ( $on_warn ) {
         $on_warn->(@_);
    } else {
         Carp::carp(@_);
    }
}

It turned out that naming the method the same as a function was a bad idea (at least in the transition to the fully refactored code). The simple application used some simple hierarchies, and when I "fixed" the superclasses as in:

package Parent;

sub carp {
    ...
}

I found after some perplexity that in the children, code like that:

package Child;

use base qw( Parent );

use Carp qw( carp );

...
   $self->carp("message");
...

emitted strange messages like:

Parent=HASH()message

because $self->carp("message") resolved to Carp::carp( $self, "message" ) as Carp::carp had been exported to Child overriding the method I was expecting to inherit.

That's what we earn because methods are just subs.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.