Re: subroutines and namespace

I'm most grateful to those who've troubled to kick in their $/50 or Ł/50 or whatever - perhaps even e/50 these days... whatever... it's been, if nothing else, an educational canter around some of the topics in this area.

I take the points against my madcap scheme. But I'm not completely convinced (yet). Often one does want to keep the subroutine completely independent of the calling scope. But sometimes one (by which I mean "I" - and it may be this is a sign I'm getting other things wrong) have several different scopes that repeat the same, or roughly the same, bit of code. Just a little snippet, nothing fancy, but repeated a dozen times it begins to get heavy.

And I know the canonical solution to this added weight is

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

But at the same time, it wd just be nice to be able to write that snippet out once only. 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.

Likewise if the result is a proliferation of global variables, that's a bad idea - I'd like the variables in the subroutine to go out of scope when I leave the calling scope. And full-qualified variables are at least aesthetically unattractive.

What I'd like is a pragma that I can use at the start of a package that merges that package's namespace with the namespace from which it was called. I don't know from perlguts, so this may be an impossible dream. And I'm still ready to be convinced it's a mad dream, or that it's a dream that is already a reality if I but knew how to do it. But it IS still my dream...

§ George Sherston

Comment on Re: subroutines and namespace Download Code

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

Replies are listed 'Best First'.

Re: Re: subroutines and namespace
by dragonchild (Archbishop) on Nov 02, 2001 at 21:46 UTC

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.

[reply]