[32845] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4111 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 8 21:09:34 2014

Date: Wed, 8 Jan 2014 18:09:07 -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           Wed, 8 Jan 2014     Volume: 11 Number: 4111

Today's topics:
    Re: Help with understanding references to subroutines <rweikusat@mobileactivedefense.com>
    Re: Help with understanding references to subroutines <ben@morrow.me.uk>
    Re: Help with understanding references to subroutines <rweikusat@mobileactivedefense.com>
    Re: Help with understanding references to subroutines <ben@morrow.me.uk>
    Re: Help with understanding references to subroutines <rweikusat@mobileactivedefense.com>
    Re: Help with understanding references to subroutines <daves@orpheusmail.co.uk>
    Re: Help with understanding references to subroutines <uri@stemsystems.com>
    Re: Help with understanding references to subroutines (Tim McDaniel)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 08 Jan 2014 17:12:07 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <87a9f6wg7s.fsf@sable.mobileactivedefense.com>

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: I'm presently working on
a mod_perl-based 'web application' (in the sense that it is supposed to
work in response to a HTTP GET request) which is supposed to create
PDF-documents containing QR-code images supposed to be used for
interacting with another web application. Creating these images requires
connecting to a database server and querying various pieces of
information from it, possibly, a lot of pieces (tenthousands). Since
this will be an autonomously operating piece of software, it needs to be
able to deal with database connections suddenly breaking down, ie,
because the DBMS was restarted as part of a system update. The way this
works is as follows:

There's a low-level database interface layer which executes queries on
behalf of the application. In case of database errors, these are
classified as either irrecoverable or transient and an exception is
thrown (via die) containing information about the error and its type.

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.

The 'application subroutines' (there's actually more than one)
themselves just perform their work without any concern for problems
which could occur while interacting with the database.

Note to the '"Download stuff from the internet!"-autoresponder': The
total size of this is 132 lines of code. The fact that some
CPAN-codeblob with presumably more than 100 times this size exists which
hopefully(!) provides this as an also-feature among the toaster,
lawnmower, hovercraft, big game trap, mail reader, howitzer and
pencil-sharpener also rolled into it is not an excuse for using that.


------------------------------

Date: Wed, 8 Jan 2014 19:54:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with understanding references to subroutines
Message-Id: <40n0qa-muh1.ln1@anubis.morrow.me.uk>


Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>
> Note to the '"Download stuff from the internet!"-autoresponder': The
> total size of this is 132 lines of code. The fact that some
> CPAN-codeblob with presumably more than 100 times this size exists which
> hopefully(!) provides this as an also-feature among the toaster,
> lawnmower, hovercraft, big game trap, mail reader, howitzer and
> pencil-sharpener also rolled into it is not an excuse for using that.

Oh, do shut up.

Ben



------------------------------

Date: Wed, 08 Jan 2014 20:24:55 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <87txdeusq0.fsf@sable.mobileactivedefense.com>

Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>
>> Note to the '"Download stuff from the internet!"-autoresponder': The
>> total size of this is 132 lines of code. The fact that some
>> CPAN-codeblob with presumably more than 100 times this size exists which
>> hopefully(!) provides this as an also-feature among the toaster,
>> lawnmower, hovercraft, big game trap, mail reader, howitzer and
>> pencil-sharpener also rolled into it is not an excuse for using that.
>
> Oh, do shut up.

Again, an argument in favour of "Whatever J. Random Bored Guy
uploaded to J. Random Software Rubbish Dump" must be used because it was
uploaded, regardless of any non-desirable properties it might have,
would be most welcome.


------------------------------

Date: Wed, 8 Jan 2014 20:49:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with understanding references to subroutines
Message-Id: <t6q0qa-4li1.ln1@anubis.morrow.me.uk>


Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >>
> >> Note to the '"Download stuff from the internet!"-autoresponder': The
> >> total size of this is 132 lines of code. The fact that some
> >> CPAN-codeblob with presumably more than 100 times this size exists which
> >> hopefully(!) provides this as an also-feature among the toaster,
> >> lawnmower, hovercraft, big game trap, mail reader, howitzer and
> >> pencil-sharpener also rolled into it is not an excuse for using that.
> >
> > Oh, do shut up.
> 
> Again, an argument in favour of "Whatever J. Random Bored Guy
> uploaded to J. Random Software Rubbish Dump" must be used because it was
> uploaded, regardless of any non-desirable properties it might have,
> would be most welcome.

Oh, do shut up.

Ben



------------------------------

Date: Wed, 08 Jan 2014 21:36:39 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <87lhyqupeg.fsf@sable.mobileactivedefense.com>

Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> >>
>> >> Note to the '"Download stuff from the internet!"-autoresponder': The
>> >> total size of this is 132 lines of code. The fact that some
>> >> CPAN-codeblob with presumably more than 100 times this size exists which
>> >> hopefully(!) provides this as an also-feature among the toaster,
>> >> lawnmower, hovercraft, big game trap, mail reader, howitzer and
>> >> pencil-sharpener also rolled into it is not an excuse for using that.
>> >
>> > Oh, do shut up.
>> 
>> Again, an argument in favour of "Whatever J. Random Bored Guy
>> uploaded to J. Random Software Rubbish Dump" must be used because it was
>> uploaded, regardless of any non-desirable properties it might have,
>> would be most welcome.
>
> Oh, do shut up.

http://en.wikipedia.org/wiki/Sturgeon%27s_Law

There are

	- some CPAN modules I use because they provide functionality
          orthogonal to 'the core of the application' which is also
          needed but I don't desire to deal with it in more detail
          except if there's a critical bug in the module

	- some CPAN modules I use because they saved me a significant
          amount of work despite they're earmarked for replacement
          because of known deficiencies should time permit

	- some CPAN modules I use because I consider them 'generally
          well-designed and useful' for the purpose at hand, possibly
          extended with features I happen to need the module author(s)
          were less interested in

	- some CPAN modules I wouldn't touch with a ten feet barge
          pole, generalized event loops, kitchen sink abstractions
          solving wildly differing problems, OO systems of any pedigree
          (if I though the Perl OO system was seriously unusable, I
          wouldn't be using Perl) and generally (or mostly) everything
          which is supposed to solve 'programming problems' instead of
          'real problems'

YMMV.


          
        


------------------------------

Date: Wed, 08 Jan 2014 23:26:26 +0000 (GMT)
From: Dave Stratford <daves@orpheusmail.co.uk>
Subject: Re: Help with understanding references to subroutines
Message-Id: <53c704616fdaves@orpheusmail.co.uk>

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?

Sorry if this sounds a bit basic, but having programmed in a large number
of different, occasionally esoteric, languages for just over 30 years, I
can't think of an instance where this has even been possible before. I
have written a couple of largish cgi scripts in perl, and not needed to
use them.

Dave




------------------------------

Date: Wed, 08 Jan 2014 18:34:03 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Help with understanding references to subroutines
Message-Id: <87zjn66ob8.fsf@stemsystems.com>

>>>>> "DS" == Dave Stratford <daves@orpheusmail.co.uk> writes:

  DS> Thanks for all the help and advice guys. I'm still not 100% sure I
  DS> understand it enough, but at least I do know that there is a reason.

it is much simpler than you realize. it is just a mindset change that
you need to make.

it is just that code can be treated like data (lisp is all about
that). so you can put code into data structures, pass code as arguments,
etc. a very common use of code refs is a dispatch table. it is a hash of
keys but the values are code references. this way you can choose which
sub to call based on some key. i am sure there are plenty of perl
examples all over usenet and beyond.

so a sub reference is just a scalar value that refers to a sub and which
can then be called. it can be created from a named sub or by an
anonymous sub (just like with named or anon hashes and arrays).

an example of a sub as an argument would be choosing different ways to
output something. the sub could be printing to a file, logging, etc. the
main sub is passed its args and a sub to control output. when it has
output it calls that sub and passes it stuff to output.

this is also called polymophism. each of the subs you can pass in must
(should) have the same api. that way the main sub doesn't have to do
anything special but use the single section of code to call the sub
ref. same with the above dispatch table. all of the subs in it should
take the same args and return the same type of value (if they return
something).

so think of sub refs as an elegant and efficient way to choose something
at a distance. instead of a long ugly if/then/else block you just need
to choose the correct sub (from the dispatch table or via passing it in
as an arg). like most software tricks it isn't NEEDED but very useful
and popular. but then again, most software things are just sugar over
assembler too. :)

uri




------------------------------

Date: Thu, 9 Jan 2014 01:08:41 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Help with understanding references to subroutines
Message-Id: <laksqp$qmf$1@reader1.panix.com>

In article <53c704616fdaves@orpheusmail.co.uk>,
Dave Stratford  <daves@orpheusmail.co.uk> wrote:
>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?

That's like saying "Why do you need refs/pointers/subscripts?
Couldn't you just set the variable itself?"  That's practially like
advocating

    if ($i == 1) {
        $a1 = $x;
    } elsif ($i == 2) {
        $a2 = $x;
    } elsif ($i == 3) {
        $a3 = $x;
    ...

and not realizing that there's a problem with using a value that's not
hardcoded (what if you implement $a1 through $a100 and then need
$a101?), and professing not to see any use for

    $a[$i] = $x;

>Sorry if this sounds a bit basic, but having programmed in a large
>number of different, occasionally esoteric, languages for just over
>30 years, I can't think of an instance where this has even been
>possible before.

Haven't you ever used Perl's sort, map, or grep?  I'm told they are
not quite sub references, but they look enough like them to be a
useful mental model for me.  How about $SIG{...}?  You give them sub
references.

What languages have you used?

In C, they're function pointers.  In standard libraries, they are used in
    atexit: register a function to be called at program exit (like
        Perl's $SIG{__DIE__}, I think)
    bsearch, qsort: search and sort don't know the datatypes of what
        they're sorting, so you pass in a comparison function
    signal: register a signal handler function (%SIG)

In Fortran, they are EXTERNAL arguments.  I used them in math -- for
example, you have a Runge-Kutta solver but you need to pass it a
function that you're trying to integrate.

In Java, I think they tend to use interfaces, so I think you create a
class that implements the interface, and in that class have a method
with the standard name that does what you want.  You're not passing a
pointer to a method -- but you are passing a pointer to an object that
happens to call the particular method you want to run.

-- 
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 4111
***************************************


home help back first fref pref prev next nref lref last post