I'm confused by the answers you have received so far in this thread.

Firstly, if the Module in question is a OO style module, then the only time you need to use the full module name is when you instanciate it:

my $BUGA = Bric::Util::Grp::Asset->new();

from that point on, every method you call upon that instance, you call with the syntax:   $BUGA->method( @args );

Where modules have procedural interfaces (or class methods), then the usual mechanisms for importing individual entrypoints or predefined groups of enterypoints is to use the use Module IMPORT-LIST; syntax (See perlfunc:use.

A breif look at the Bricolage stuff shows that many of the (many, many!) modules support this syntax for importing individual api's or in groups through the use of group selectors ':standard', ':all' and others.

So, in answer to your question: Shouldn't use do this?, I would say the answer is: Yes, and it does:).

Of course, it requires that the modules in question support the syntax, but in the case of Bricolage, it seems that most if not all of them do in as far as it makes sense to.

As for why the Bricolage documentation doesn't exemplify this, choosing to show every call in the full

Module::Submodule::SubSubMod::SubSubSubMod::function()

form (and yes, they really do go that deep!:), I can only speculate at. I did notice that there seems to be an uncommonly large amount of re-use of namespace at different levels of the hierachy, (eg. Asset.pm, Addr.pm, Auth.pm, Contact.pm, Data.pm all appearing twice in the tree, Action.pm appearing 3 times etc.)

Maybe they use the fully qualified names to ensure distinction. Maybe also, if you import :all from two or more of the individual modules you end up with namespace clashes?

If this is the case, then using an auto-import-everything-from-this-module routine is only going to compound matters further as you are likely to import similarly named private routines from the modules too.