Welcome to the Monastery, previous!

$self->{sub_ref}->(); should do what I think you want. It simply executes the sub from within the object instead of first assigning it to a temporary coderef. Unless you need to pass the method around, this is the common way to do this.

It's even possible to reduce the statement by two whole characters! — although I would argue that the code is de-clarified by doing so:

c:\@Work\Perl\monks>perl -wMstrict -le
"sub mysub { print 'hiya'; }
 my $hr = { sub_ref => \&mysub };
 $hr->{sub_ref}();
"
hiya
[download]

---

Give a man a fish:  <%-{-{-{-<

I noticed that too, but I don’t see it documented. The closest I’ve come are two references to eliminating arrows between “brackets subscripts” — perlref#Using-References (3) and perlreftut#Arrow-Rule. Or does a pair of parentheses () also count as a “subscript”?

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

Some golf code can have the advantage of clarifying the question by being read quickly. It may be more for quick examples because in production code spelling things out more may make for easier debugging and modification.

It later occurred to me that you don't always need a subroutine reference to call outside an object or package although it could be useful. If the call is not object dependent you can just specify the name of the other package like "main::hello()".

I included my simplified/golfed example below:

package C;

sub new {
    my $self = shift;
    my $class = ref($self) || $self;

    return bless {sub_ref => shift}, $class;
}

sub doit {
    $_[0]->{sub_ref}();

    # you don't always need a reference to call outside of an object
    main::hello();
}

package main;

sub hello {
    print "hello\n";
}

C->new(\&hello)->doit;
[download]

Ron

Last time I checked, ASCII characters were still free.   And, last time I checked, computer programmers were not.

Also, most of those programmers are not spending their days writing new code.   They are wrestling with existing, revenue-producing code bases (“legacy code”) which might be decades old and worked-on by more than a hundred different people over those years.

Therefore, what’s really most-important in your source code is:   clarity.   For instance, using a more meaningful name than sub_ref, and maybe deliberately using a local variable (named, say, $ajaxRequestCallback instead of $pSub ...) to clarify to the next guy exactly what it is you’re calling and why.   (And if his future modification, written three years after you got smooshed by that most-unfortunate bread truck, needed to call the subroutine twice or under slightly different conditions, your “wasteful” use of a few extra lines or characters will have helped him a little.)

Not meaning to preach here ... (honest) ... but over these years I have just seen so much “cleverness,” and in so many different languages.   Clarity and simplicity in the original coding makes a high-dollar difference in the sort of “project turn-around, I See Dead Projects™” work that I do so much of.   Speaking therefore as the one who cleans up after you:   “Please don’t try to economize on bytes or lines.   Ever.   Instead, make it as easy as possible for us to read your mind, given that we cannot dig you up to ask.”   Thank you.   ;-)

That's a knee-jerk reaction.

Sometimes, short and concise code is clearer than long code (and that's why I prefer Perl to Java or Ada), and sometimes not.

Granted, clarity is of paramount importance, but long code is no guarantee for clarity, really not. (And no, I am not advocating golfing.)

sundialsvc4: *outgassing*

Laurent_R: That's a knee-jerk reaction....

What do you expect from a non-programming piece of poo? After all these years posting on perlmonks, he still can't write a valid line of perl. sundialsvc4 calls code that uses grep golfing ... hes stupid