return ($ref_booking, $ref_course, $ref_event);
}
[download]

my ($ref_booking, $ref_course, $ref_event) = 
    GetStuffFromDB($my, $parameters, $here);
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Yes, that'd do it. Very neat - possibly nicer than the solution I went with, of using fully specified package variables from my module. Only disadvantage is a few more characters of code... which are marginal even if I'm intent on Higher Laziness.

My main point was a general one, however, that sometimes one wants to have subroutines with the same scope as the point from which they're called. Just as often one does *not* want this. I wondered whether I was alone in thinking this might be a useful thing to be able to do - in a lot of different situations.

§ George Sherston

Actually, you would never want to care where the subroutine's scope is. And, the reason why is that it would violate encapsulation.

The way to think about a subroutine is that it's a self-contained unit of activity. It receives inputs, does stuff, and gives outputs. It should NEVER depend on the caller's scope. It should NEVER depend on anything but that which is within its own personal scope (which should be inviolate and untouchable by caller).

Every single legitimate reason you would want to do what you suggest is negated by a language feature or design change that will make your code more maintainable and easier to work with.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Why not have an optional hashref that you pass in, such that if it is defined, you store the results there, otherwise you create a new one and return that?

sub do_something {
    my ( $normal_arg1, $normal_arg2, $optional_hashref ) = @_;
    my $hashref = $optional_hashref ||  { };
    #
    # ...time passes...
    #
    $hashref->{ return1 } = "foo";
    $hashref->{ return2 } = "bar";
    return $hashref;
}

my %hash;

my %newhash = do_something( $this, $that );
do_something( $this, $that, \%hash );
[download]

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

The point about statically scoped (my) variables is that what they refer to can be completely determined by their point of definition. So if I say

my $foo=17;
sub quux {
  my $bar=29;
  $foo = baz($foo,++$bar)
}
[download]

What you're after is global variables. You want some variable defined in one place in your program to get modified in an entirely different place. Why is this bad?

Well, consider this code:

use vars qw/$foo/;
sub quux {
  my $bar=29;
  $foo = baz($foo,++$bar)
}

# ...code passes...
$foo = 11;
print quux($foo), "\n";

# ...more code...
{
  local $foo = 39;
  print quux($foo), "\n";
}
[download]

Variable lookup with global variables is akin to spaghetti. You can eat it, but there are healthier alternatives...

Yeah, but nothing else that takes 5 minutes to make tastes as good. (Maybe that's an analogy?)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I think there is, though it would involve some XS programming. If you can find the CV (internal data structure holding a subroutine) you want to duplicate, you could theoretically copy it and change its stash value (lexical scope, basically) and stick it in the appropriate GV (symbol table). Any XS hackers out there care to enlighten us?

Barring that, is there a reason you can't use a closure?

sub make_booking_SQL {
    my ($BookingID, $ref_booking, $ref_event, $ref_course) = @_;

    return sub {
        $sth = $dbh->prepare("SELECT * FROM booking WHERE BookingID = 
+$BookingID") or die $dbh->errstr;
        $sth->execute();
        $ref_booking = $sth->fetchrow_hashref;

       $sth = $dbh->prepare("SELECT * FROM event WHERE EventID = $ref_
+booking->{'EventID'}") or die $dbh->errstr;
       $sth->execute();
       $ref_event = $sth->fetchrow_hashref;

       $sth = $dbh->prepare("SELECT * FROM course WHERE CourseID = $re
+f_booking->{'CourseID'}") or die $dbh->errstr;
       $sth->execute();
       $ref_course = $sth->fetchrow_hashref;
    };
}
[download]

This is bad because getting the information to the subroutine requires that you correctly name the variables in the enclosing scope and there is no way to catch mistakes.

It is also bad to have the subroutine tell the caller what variable names to use. What if I want to write some code that uses your subroutine twice? I can't have two different variables both called $ref_booking!

$RAM->buy('more')
[download]

On the other hand, if I have to surround it with variable declarations and mechanisms for recovering variables, and if I have to pass it a whole load of arguments (and think about which arguments I'm passing) then it begins to be more trouble than it's worth.

This sounds like you're not factoring your functions enough, nor are you documenting your functions. If you design good functions (especially naming!!), then they will tell you how to call them. They will tell you what they need and how much of it they want. Don't throw the baby out with the bathwater, my brother. Try it for a month and see how you like it.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

$dbh->disconnect;
[download]

package whatever;

...

@EXPORT = qw( $routine );


$routine = q^
$thing = something+something_else;
lots and lots of code;

^;

sub routine [
my ($thing, $other_thing) = @_;
eval $routine;
}

package main;

my $thing;
my $other_thing;

eval $routine;
[download]

If you want to run routine in local scope, eval $routine it. If you don't want it messing with your variables, call it with routine()

____________________
Jeremy
I didn't believe in evil until I dated it.

Warning. That eval solution needs error checks. Else you could get very confused working out why you are getting no result, when the problem is that $routine expects to be sharing some variables with its environment, the environment doesn't have them, and strict finds this to be a situation worth complaining about.

(Just to list one non-obvious way that a non-trivial error in $routine may need to be handled.)

UPDATE
Re the reply, I understand fully. I just like pointing these things out because you have to expect people to just lift code from here directly without understanding the issues. So if you are posting it as a suggestion, it should look like production code.

That said, I find the eval solution painful on the face of it. I would prefer to solve that with just using Filter::Simple and a few well-chosen macros. If I was going to solve things that way. Which I would probably avoid for reasons listed above...

The perils of doing an off-the-cuff answer to a post. When I implemented it I eventually had buckets of error checks in the routine itself (e.g.  if defined) and checked the results with an or die "\$routine failed with error $@". I also had almost every second line printing into a log file (my personal favourite way of documenting code).

But after that there's not much difference between the evals and real subs except some faulty code can stomp all over variables in your current namespace.

____________________
Jeremy
I didn't believe in evil until I dated it.

#!/perl/bin/perl
#
#  --
use strict;
use warnings;
use diagnostics;

my $test = "hello world\n";
my $stub = sub {$test = "goodbye world\n"};
print $test;
&$stub;
print $test;
[download]

hsm