It's your module, do what you like! You won't see a lot of code excluding imports. You will see:

use Module qw( :utils );
use Module qw( util1 util2 util5 );
use Module qw( :utils_basic );
[download]

You can define any export sets you want. The bottom line is that it will make very little load/runtime diff if you import the extra unused functions.

Personally I generally shun import tags. I like to ask for each and every function by name as when someone else comes to look at the code it documents where the function lives ie which module:

use Module ':all';
use Other  ':all';
# etc

.....

func(); # "!£$^%^! where the hell did this come from?
[download]

I like importing as it save long function names. It does make it harder to track the source module. ':all' or whatever makes it harder still.

Abigail

Thanks Abigail!

I suppose it's like a toolbox with different compartments of tools for varied purposes. If you have some repair work to do and you know you only need tools from the first compartment, do you want to carry the whole box with you or do you want to take some trouble and bring only tools from that first compartment.

Well, if the box weighs .0001% more with all the tools than just the tools I want, and some effort to sort through the tools to pick out the ones I want, I'd probably just take the whole box and use the ones I need. Presumably the tools are related somehow (they are in the same box), it isn't at all unlikely that I might need one I hadn't planned on using initially...

Don't import anything and use namespaces to be explicit where every function is coming from.

That requires you to look up where each function is defined, which almost breaks encapsulation. If you do use Module;, and get a function func imported to your name space, it doesn't mean you got Module::func. Module could have use OtherModule itself, and you might have gotten OtherModule::func.

Do you use this style for OO programming as well? Do you call methods in this way: $obj -> Class::method? If not, why? Or can you remember where all the OO methods are defined, but not the procedurial subs?

Abigail

This way when you go back to your 10,000 line application, you know exactly where every function is defined.

That's what ctags and M-. (or :tag for the heathens) are for . . . . See also ECB.

A reference in your package will be faster to run, since it doesn't need to look in a different STASH to find the reference, but this is again not soo much faster.

I recomend to always import what you need, and to not use the full path until the module package. But if you want to exclude some automatically imported stuffs, this will be good only if what you are excluding is an amount bigger than what you really need. Soo, if you want to exclude only 2 or 5 methods, this is not much better than just let to import the defaults. But if you want only 2 references, and the module exports by default 20 references, well, will be good to only get the 2 that you need.

But note that this will make differences only when you load the module, soo, think always if the work pay enough to be done. In other words, when talking about programms, you should spend time optimizing only when you really win memory or speed. Soo, keep your eyes in the codes that are executed a lot, like loops, or that takes more time, like read an IO.

Good luck.