With the explicit approach, you can't conveniently swap the called function for another function unless you do that swap globally:

#use Cwd 'getcwd';
require Cwd;

# use either the stock getcwd()
*getcwd = \&Cwd::getcwd;
print "Locally, with stock getcwd() aliased\n";
which_one();

# Or our fake getcwd(), where we always claim to run under tmp:
*getcwd = sub { "/tmp" };
print "Locally, with stock getcwd() aliased to our fake getcwd()\n";
which_one();
[download]

thanks for your response

To my way of thinking, the rule begins-and-ends with:   clarity.   If the functions that are defined in the package are “distinctively named,” and can really only originate from one place, then I personally don’t mind a use or require.   Not at all.   (If the package in question is a utility-package that has lots of functions in it, I want to see an explicit list.)

To my way of thinking:   “nevermind what the computer thinks of what you’ve written ... you’re talking to me.   Make your source-code clear to me.

• If the mention of an explicit package-name adds no useful meaning to me, probably omit it.
• Since the package-name and the subroutine-name will be a single thing that my human-eye will scan “as one,” repetition of the package name will make it less likely that I will notice changes to the right-half ... the subroutine.   The more times my human-eye sees the same thing (the package-name ...), the less likely it will be to detect differences (the subroutine).   (Paris In The The Spring and all-that ...)
• If the subroutine-name is identical between two-or-more packages, and you are using package names as qualifiers to dis-ambiguate between them, then ... uhhh ... “that stinks ... don’t do that.”

The computer, being a machine, can “figure out” a lot of things that the humans who will follow in your footsteps could easily overlook and/or misinterpret.   Therefore, never-mind the machine.   Write for the humans.   “Make the trail of bread-crumbs both obvious and tasty.”

Interesting. I agree whole heartedly with your "clarity" sentiment, but disagree that omitting the "name space" (package name) is the way to achieve that.

If I encounter code that I'm not familiar with and it uses external libraries (nomenclature chosen to reflect the cross language nature of the issue), then I much prefer some indication of where a function or procedure comes from so I have some hope of finding documentation for it (which may be the source code).

For me the usual "the first thing is most important" seems to be adjusted in the context of name spaces so I don't have the repetition problem you mention. Guess I've developed a built in filter that kicks in in that context.

Often there is one clear and sensible name for a function or procedure so using an alternative name to avoid name conflicts reduces the value of the name. In fact I find it annoying that different languages go out of their way to use different words for the same thing, seemingly just to prove they are language X and not language Y.

Of course almost all this issue goes away if you use OO techniques. An object knows what it is and an intent with object procedures is that you use the same name for the same action in many different contexts. So the best of both is that you use name spaces to qualify constructors, then using procedure names with objects provides all the context you need to understand the provenance of the procedure call.

Perl is the programming world's equivalent of English

/me nods ... respectfully, agreeably, and silently ...

I share your opinions as-expressed exactly.