in reply to Re: Object Method Call
in thread Object Method Call

... you will notice the problem if you attempt to use $self in display.
However, if the call (from within the  test() subroutine) had been
    display($self);
there would have been no problem: this would have emulated the effect of the  -> operator and a
    $self->display;
call.

This just reinforces moritz and dreadpiratepeter's point that Perl does not know what's in your mind, only in your code.

Replies are listed 'Best First'.
Re^3: Object Method Call
by Bloodnok (Vicar) on Jul 26, 2009 at 23:53 UTC
    How could perl possibly know what's in _my_ mind ... all too frequently, I've absolutely no idea - as I capably demonstrate thro' my rambling postings here :-D

    Sits back and wonders whether the telepathy engine in perl6 will be more than a figment of someones' fevered imagination ;-|

    </silliness>

    A user level that continues to overstate my experience :-))
[reply]
Re^3: Object Method Call
by bkv2k (Novice) on Jul 26, 2009 at 17:44 UTC
    Thanks all for the help!
[reply]
Re^3: Object Method Call
by afoken (Chancellor) on Jul 27, 2009 at 12:06 UTC

    But there is a slightly difference between display($self) and $self->display(), when a class XY inherits from MyTest and implements it's own display() method. display($self) calls MyTest::display() even when invoked on an instance of XY, whereas $self->display() calls XY::display() when invoked on an instance of XY. So, one could say that display($self) breaks inheritance. This is often bad, but sometimes, it can be a useful trick.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      That usually occurs when you're overriding a method, in which case $self->SUPER::display(); will do the trick.
[reply]
[d/l]

        Yes, SUPER:: is the usual way to access the super method. But the evil trick of invoking a method as a function with the object as first argument is different. It completely prevents overriding that method, no matter how deep the inheritance tree is. I know it is evil, confuses everyone, and is a sure sign of a broken design. But in very rare cases, it can be useful, even if it breaks the design even more. See Re^5: Object Method Call.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
      So, one could say that  display($self) breaks inheritance.
      It certainly does that if  display is a method.

      This is often bad, but sometimes, it can be a useful trick.
      Hm. Well, I would agree with the word bad, but I think I would delete often unless the goal of the trick is to confuse the heck out of yourself and everyone else. For me, it's hard enough to keep everything in OO programming straight without deliberately trying to trick myself.

      I'm curious: Can you give an example of how this trick might be productively used?

[reply]
[d/l]
[select]

        Hmmm, I remember having used that trick only once in my life, but the project has been administrated to dead (long story about clueless interns working as admins, dieing harddisks, missing monitoring systems, and insufficient backups). It was a crude class hierarchie that should have been refactored. At one point, the usual inheritance would have broken things if a certain method was overwritten. I don't remember the details and the sources are lost, but it was nasty and had a comment marking that trick as "evil but required".

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

In Section Seekers of Perl Wisdom