in reply to Re: POE OO sessions - accessing overwritten methods
in thread POE OO sessions - accessing overwritten methods

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

Replies are listed 'Best First'.
Re^3: POE OO sessions - accessing overwritten methods
by Tanktalus (Canon) on Feb 12, 2005 at 15:30 UTC

    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]

        Interesting. But they are quite wrong (see above). They start out with a factual truth: passing in by @_ is fastest. (I wonder if passing in a single array ref would be faster ... one way to find out!) However, they then go and explain how they'll use this "fast" method to go and make it readable and extendable. Well, guess what. It's not.

        Rather than starting out with the fastest method and making it more readable, they should have evaluated all methods, and picked the most readable and fast method. They discarded all alternatives over a perceived speed difference, and then used up way more than that speed difference in making it readable. Kudos for making it readable and forward-thinking. A pox for thinking inside an artificial box.

        Update: Yes, a major typo in the code screwed this up. Ok, so it's not significantly slower. I still think it's unreadable :-)

        Read more... (2 kB)

        Short version: The calling types they said would be slower than "normal" are. But they're all faster than the one they ended up with. The unintuitiveness of this style still causes problems. As in calling SUPER.

[reply]
[d/l]

      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