Many modules by default export a bunch of functions into the current package (whatever has the use Mymodule; in it). By including an empty list in the use you explicitly forbid anything from Mymodule being exported into the package name space. That doesn't stop you accessing the module's functions however. You just prefix the function name with the module name: Mymodule::wibble () for example to call the wibble function from the Mymodule module.

Why bother? Well, modules tend to be designed in isolation so very often functions that perform similar tasks get the same name in different modules. If all the functions were imported from every module that is used in a package then the chance of collisions between function names becomes very high - using name spaces as above completely avoids the problem.

Another advantage of using explicit name spaces is that then it is clear where the function comes from. I always use CGI with an empty list for example and then either use the OO interface CGI provides or call functions using an explicit CGI:: prefix.

If MyModule has exports you don't want, passing an empty list as an argument will keep them from being imported. You still need to load the module, however, if you want to do something like MyModule->new.

That module MAY export some functions, etc. by default, which action you can override with the empty parentheses. (You may find jasonk's statement clearer) But note, you will have access to those when your code includes use MyModule; and subsequently specifies some particular exportable therefrom.

So, if you wish to make use of some exportable function from a module when (and only when) a particular condition in your code is reached (think "dispatch table", for example) but another exportable function if a different condition is reached, you might find the empty parentheses useage handy (when followed by the likes of MyModule -> new in a dispatch table (or elsewhere).

• perldoc perlmod
• The Tutorials here, under the heading "Modules: How to Create, Install, and Use"
• Printed discussions such as those in "Intermediate Perl"

Sometimes it's also valuable to be able to have CGI::Dump and YAML::Dump and XYZ::Dump all within reach but not stomping on each other through an exportarama. Also it makes us feel more sympathy for our disadvantaged brethren when we're able to type-

my $it = Org::PerlMonks::WWW::Everything::View::Page::Nodelet::DailyBe
+st::GetIterator();
[download]

This is essentially the same answer as others have provided but if you don't understand their answers perhaps this manner of expressing them will help...

'use Mymodule ();' causes Mymodule to be loaded without calling its import() subroutine. This makes the subroutines of the module available and will cause BEGIN, UNITCHECK, CHECK and INIT blocks to be executed if they exist.

The import() subroutine of many (not all) modules will add variables or subroutines to the callers name space.

You sometimes want to load the module but do not want it to add anything to your name space. For example - you may have your own subroutines of the same name as the module would create (import) if its import() subroutine was called.

Having loaded the module, you can access its subroutines using fully qualified subroutine or method calls. For example, Mymodule::some_subroutine() or Mymodule->some_method.

In some modules the import() subroutine does other things as well as or instead of importing names into the callers name space. If the module is doing initialization in its import() subroutine, then it may not work as expected when you prevent the subroutine being called. You should read the documentation or the code of the module you are using to be sure.

By default, many modules will export symbols ... into the "main::" namespace.

That is incorrect, but it is often what happens because the use Module statement is in the package main. The symbols are exported to into the current namespace.

Be well,
rir