http://www.perlmonks.org?node_id=1015838

Doctrin has asked for the wisdom of the Perl Monks concerning the following question:

Hello :) Could anyone tell me the practical difference between following:
use Algorithm::LUHN;
and
use Algorithm::LUHN qw /is_valid/;
Is it somehow better to use the second statement if I use only "is_valid" method in my code? Maybe, memory issues or something? Thanks in advance.

Replies are listed 'Best First'.
Re: Difference between use Module::Name and use Module::Name qw /method1 method2/
by choroba (Cardinal) on Jan 29, 2013 at 10:06 UTC
    In fact, it depends on the module in question. But, if the module uses Exporter, the second option only imports is_valid into the current namespace. All other functions still exist under their fully qualified names, so the memory should not matter. But, if the module exports a subroutine called "all" or something similarly simple, you can avoid a clash with your own "all" subroutine. The qw way keeps your namespace clean and under better control.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: Difference between use Module::Name and use Module::Name qw /method1 method2/
by LanX (Saint) on Jan 29, 2013 at 10:10 UTC
    From what I can see from the source of Algorithm::LUHN nothing is exported by default:
    @EXPORT = qw//; @EXPORT_OK = qw/check_digit is_valid valid_chars/;

    so if you wanna import is_valid you need to tell explicitly.

    see also How to Export

    EDIT

    > Is it somehow better to use the second statement if I use only "is_valid" method in my code? Maybe, memory issues or something?

    No! No significant memory problems, importing is a kind of aliasing between namespaces.

    But you have to care about potential namespace polution, see Selecting What To Export.

    Please note that you don't necessarily need to import is_valid, otherwise can also address Algorithm::LUHN::is_valid directly.

    Cheers Rolf

Re: Difference between use Module::Name and use Module::Name qw /method1 method2/
by tobyink (Canon) on Jan 29, 2013 at 11:18 UTC

    Formally, the syntax of the use statement is such that...

    use Foo::Bar; # is equivalent to: BEGIN { require Foo::Bar; Foo::Bar->import(); }; # and with parameters: use Foo::Bar ...; # is equivalent to: BEGIN { require Foo::Bar; Foo::Bar->import(...); };

    The only slightly surprising case is an explicit empty list:

    use Foo::Bar (); # is equivalent to: BEGIN { require Foo::Bar; };

    ... and the import method is not called at all!

    So the question comes down to; what is the difference between these:

    Algorithm::LUHN->import(); Algorithm::LUHN->import(qw/is_valid/);

    import is just a regular old class method; nothing special about it. So the difference between those is whatever the author of Algorithm::LUHN wants it to be.

    Nonetheless, there are some conventions for the parameters to the import method. While they're just conventions, they're quite widely followed...

    If you supply a list of words (like "is_valid") to the import method, it indicates that you want to import the listed functions into your own namespace. So, given:

    Algorithm::LUHN->import(qw/is_valid/);

    You're saying you want to copy Algorithm::LUHN::is_valid to Your::Package::is_valid. This is really an alias rather than a copy, so uses negligible memory, and negligible CPU (unless you're aliasing dozens and dozens of functions). A bigger concern is often namespace pollution - it means you no longer have the freedom to define your own is_valid function in your package.

    If the list of words includes some prefixed with ":" or "-", these often refer to "bundles" of functions. So for example, Algorithm::LUHN could define a :validity bundle which included "is_valid" and also "get_validation_errors". So calling:

    Algorithm::LUHN->import(qw/ :validity /);

    ... would import both functions.

    If you don't pass any import parameters at all, the convention is that the module will choose some "default" list of things to export to your namespace - which may be nothing; or may be everything; or may be somewhere in between.

    Of course, just because you request some function to be exported; there's no guarantee that it actually will - the module may not offer the function you requested. In these cases it is convention for the import method to croak

    Those are the conventions; there's no rule that says anybody must follow them, but if one does deviate from them, then it's polite to document ones deviation!

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: Difference between use Module::Name and use Module::Name qw /method1 method2/
by moritz (Cardinal) on Jan 29, 2013 at 10:44 UTC

    In this specific case, supplying an import list (the qw/is_valid/ part) imports that symbol, leaving it out imports nothing.

    In the general case, the import list is passed to the loaded module's ->import function, and it can do whatever it wants to do.

    But many, many modules are based on Exporter. For Exporter-based modules, not specifying an import list gets you all the symbols listed in the default exportation list called @EXPORT. Specifying an import list disables that default, and instead gives you the symbols you asked for, if they are listed in @EXPORT_OK. If they are not, you'll get an error.

    In most cases, importing doesn't affect performance to any discernible degree, but it is often easier for maintenance to list exactly the symbols you want to import. If you have many use statements, it's easy to search for which module gave you a particular symbol.

    But it is worth mentioning that a few peculiar modules (if I remember correctly, POSIX and/or CGI) have quite many symbols, and only compile the routines to be exported as requested. In this case, it can make a noticeable difference in start-up time if you import all routines.