in reply to POE OO sessions - accessing overwritten methods

You need to always shift off $self if you're going to use @_ again.: 

sub client_start
{
    my $self = shift;
    # this is an overwritten method!!!
    my ($kernel, $heap, $session) = @_[ KERNEL, HEAP, SESSION ];
    # child code goes here
    # [...]
    # now, access the overwritten parent method
    $self -> SUPER::client_start( @_ );
}

[download]
$self has to be the first param, so your OBJECT is kinda redundant, IMO

Replies are listed 'Best First'.
Re^2: POE OO sessions - accessing overwritten methods
by m-rau (Scribe) on Feb 12, 2005 at 10:44 UTC
    Thanks for your advice. But from my point of view, there is a problem with this solution.

    Designing client_start like this breaks down the regular call of the parent's client_start. In OO design, the OBJECT constant contains 0 and the KERNEL constant contains 1. If I remove $self from @_, KERNEL still refers to 1 and I cannot access it utilizing my ($self, $kernel, $heap, $session) = @_[ OBJECT, KERNEL, HEAP, SESSION ];.

    But I found the solution in http://poe.perl.org/?POE_Cookbook/Object_Methods:

    Disadvantages

    * Some people don't like OO.
    * Because @_ has so much in it, one has to do silly 
      things like shift(@_)->SUPER::subroutine(@_); 
      to call parent POE-related methods.

    [download]
    With this rational to access overwritten parent methods, client_start can keep my ($self, $kernel, $heap, $session) = @_[ OBJECT, KERNEL, HEAP, SESSION ];.

    The solution is in sync with your advice and with holli's very general comment, too. Problem is, that both advices do not really reflect the special POE object design :-)
[reply]
[d/l]
[select]

      Thanks for the update ... although I have to say, I like OO, and I don't like this. I've thought about investigating POE in the past - but something like this would drive me completely away from it. I would rather get named parameters than this. In fact, named parameters would be faster than this, too. I'm really not sure what they're trying to do with this - it's unintuitive, it's ugly, and it's slow. (Funny how that works in perl - often the intuitive, clean solutions are pretty darned close to the fastest, too.)

      Read more... (1458 Bytes)
      Given all that POE has to do, This design decision seems crazy unintuitive to me.

      Update:Typo fixed, changing the way the benchmark worked. Still find it ugly :-)

[reply]
[d/l]
        POE actually answers the question Why does POE pass parameters as array slices? with: Perl functions receive their parameter values in a special list, @_. This is faster and shorter than passing parameters by hash or hashref.

        See http://poe.perl.org/?POE_FAQ/calling_convention.
[reply]

        You really should use strict, and verify that your benchmark is doing what you think it is.

        See my reply to your other bad benchmark post below.

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
[reply]

In Section Seekers of Perl Wisdom