in reply to subroutines and namespace

Maybe I'm missing something extremely simple, but why don't you just end your subroutine with 
    return ($ref_booking, $ref_course, $ref_event);
}

[download]
and then, when you call the subroutine, call it like: 
my ($ref_booking, $ref_course, $ref_event) = 
    GetStuffFromDB($my, $parameters, $here);

[download]
Or, is there some reason you didn't mention that would prevent this from happening?

------
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.

Replies are listed 'Best First'.
Re: Re: subroutines and namespace
by George_Sherston (Vicar) on Nov 02, 2001 at 18:42 UTC
    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
[reply]
      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.

[reply]

In Section Meditations