[32847] in Perl-Users-Digest
Perl-Users Digest, Issue: 4113 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 10 05:17:33 2014
Date: Fri, 10 Jan 2014 02:17:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 10 Jan 2014 Volume: 11 Number: 4113
Today's topics:
Re: Help with understanding references to subroutines <rweikusat@mobileactivedefense.com>
Re: Help with understanding references to subroutines <rvtol+usenet@xs4all.nl>
Re: Help with understanding references to subroutines <rweikusat@mobileactivedefense.com>
Re: Question about language setting (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 09 Jan 2014 15:32:53 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <87wqi9i316.fsf@sable.mobileactivedefense.com>
Dave Stratford <daves@orpheusmail.co.uk> writes:
> In article <87a9f6wg7s.fsf@sable.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Dave Stratford <daves@orpheusmail.co.uk> writes:
>> > In article <fsahc9lau7s5n6a1mmc32drlmru6hs9ji1@4ax.com>,
>> > Jürgen Exner <jurgenex@hotmail.com> wrote:
>> >> Dave Stratford <daves@orpheusmail.co.uk> wrote:
>> >> [...]
>> >> >When I run it, I get exactly what I want to get, but it seems to me to
>> >> >be an excessively awkward way to decide which of two subroutines you
>> >> >want to call.
>> >
>> >> In that contrived example, yes.
>> >
>> > <snip>
>> >
>> > Thanks for all the help and advice guys. I'm still not 100% sure I
>> > understand it enough, but at least I do know that there is a reason.
>
>> I can also provide you with a simple, real example although I can't
>> quote the code since it belongs to my employer:
>
> <snip code description>
>
> That all sounds genuinely fascinating, especially the bit about creating
> QR codes; but from your descripton, granted it's only a fairly high level
> description, but are function refs actually necessary? At some point you
> are having to decide which function to call, so why do you then need refs?
> Couldn't you just call the function?
Please consider this:
,----
| Then, there's a mid-level 'execution' layer which takes a reference to a
| subroutine as argument. This subroutine is supposed to perform the
| actual application work. All of its state information is to be stored in
| my-variables created by it and any other subroutines it might need to
| call. The executor invokes this subroutine in an eval block and catches
| exceptions thrown by the database interface layer. In case the error is
| considered to be recoverable, it kills the database connection (if it
| still exists), destroys the (DBI) database handle object, waits for a
| random, short time and starts over.
`----
A contrived mockup of that could look like this:
----------
sub operation() {
die("Shit happened\n") if rand(10) <= 7;
return rand(12);
}
sub execute
{
my $sub = $_[0];
my $rc;
{
eval {
$rc = $sub->();
};
$@ and do {
print STDERR ("\t** $@");
redo;
};
}
return $rc;
}
sub random_add
{
return operation() + 12;
}
sub random_sub
{
return operation() - 3;
}
printf("random add returned %d\n", execute(\&random_add));
printf("random sub returned %d\n", execute(\&random_sub));
----------
The operations I'm actually dealing with involve communication with an
external program (database server) which might be running on a different
computer located anywhere else in the world. There's an error recovery
algorithm jointly implemtented by 'operation' (which signals the error)
and 'execute' (which retries the failed application operation in case an
error was signalled) which has to be wrapped around a number of
different 'application operations', here represented as 'random_add' and
'random_sub'. The main application logic decides which subroutine to
call but the actual call itself is performed by an intermediate
subroutine.
------------------------------
Date: Thu, 09 Jan 2014 19:50:24 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
To: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <52CEEF70.1080904@xs4all.nl>
On 2014-01-09 16:32, Rainer Weikusat wrote:
> eval {
> $rc = $sub->();
> };
>
> $@ and do {
> print STDERR ("\t** $@");
> redo;
> };
Alternative:
eval {
$rc = $sub->();
1; #success
}
or do {
my $eval_error = $@ || 'Zombie Error';
warn "\t** ", $eval_error, "\n";
redo;
};
--
Ruud
------------------------------
Date: Thu, 09 Jan 2014 18:59:04 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <8761pththj.fsf@sable.mobileactivedefense.com>
"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> On 2014-01-09 16:32, Rainer Weikusat wrote:
>
>> eval {
>> $rc = $sub->();
>> };
>>
>> $@ and do {
>> print STDERR ("\t** $@");
>> redo;
>> };
>
> Alternative:
>
> eval {
> $rc = $sub->();
> 1; #success
> }
> or do {
> my $eval_error = $@ || 'Zombie Error';
> warn "\t** ", $eval_error, "\n";
> redo;
> };
Better alternative:
($rc, $err) = $sub->();
if ($err) {
print STDERR ("A catastrophe occurred!\n");
.
.
.
}
and implement run-of-the-mill C-style error checking and handling via
'magic return values' if you want that. Which I don't.
------------------------------
Date: Thu, 9 Jan 2014 05:31:41 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Question about language setting
Message-Id: <lalc7t$98l$1@reader1.panix.com>
In article <fdc1qa-ecl1.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>You can take a ref to any not-defined sub; the sub is autovivified as
>though a forward-declaration but no definition had been seen. You can in
>fact add a definition, as long as it doesn't look like a named sub
>definition:
>
> my $x = \&BEGIN;
> *BEGIN = sub { say "foo" };
> $x->();
>
>(Note that this sub isn't a BEGIN block, and will never be invoked as
>one, not even if you call it BEGIN using Sub::Name.)
#! /usr/bin/perl
use warnings;
use strict;
BEGIN {
print "in begin\n";
*BEGIN = sub { print "in subbegin\n"; };
}
exit 0;
$ perl local/test/108.pl
in begin
$
Yeah, not a BEGIN block. As you stated, but still, harrumph.
("&BEGIN();" just before exit outputs "subbegin", as I expected.)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4113
***************************************
