in reply to Re: Using a subroutine as a module
in thread Using a subroutine as a module

Actually, better not to export at all:

in MyModule.pm: 

package MyModule;

sub new { bless {}, shift }
sub foo { "do some foo stuff" }
1;

[download]
and in the calling code: 
use MyModule;
my $o = new MyModule;

$o->foo();

[download]
$o is an object. It can have data, but in this case, it is just a way to tell perl where to find the subroutine foo(). This means you could have several different modules, each with a routine named 'foo;, and by using the object each module returns (customarily) from the call to new(), you can tell them apart. Whereas if you have the misfortune to use 2 modules that both export foo into your namespace, who knows what happens?

--Bob Niederman, http://bob-n.com

All code given here is UNTESTED unless otherwise stated.

Replies are listed 'Best First'.
Re: Re: Re: Using a subroutine as a module
by ysth (Canon) on Nov 03, 2003 at 06:25 UTC
    I would rather use class methods than create a dummy object with no other purpose than to qualify the package to call.

    File::Spec is an excellent example of when that works well.

    In the more typical case, however, you would be just as well off importing nothing and always fully qualifying your calls (e.g. MyModule::foo() ). Importing some things is a programmer convenience to save typing and improve readability. If the sub names reflect what they do, conflicts should be rare (and can always be resolved by fully qualifying).

[reply]
Re: Re: Re: Using a subroutine as a module
by Anonymous Monk on Nov 03, 2003 at 10:12 UTC

    Egads, far too many uses of OO are superfluous and/or ill advised already and now you want OO for simple library calls. Just use fully qualified package names: 

    #### MyMod.pm
package MyMod;
sub foo { "whatever" }
1;

### calling script
#!/usr/bin/perl -w
use strict;
use MyMod;
print MyMod::foo();

    [download]
[reply]
[d/l]

      Sorry, I disagree. Modularization of code is desirable. IMHO, using a dummy object to acheive this is more valid than fully qualifying the calls for the following reasons:

      • Typically, less typing, as filenames tend to be longer han variable names (in my world, at least)

      • greater flexibility - if you decide to relocate something in the filesystem, you change only your 'use' and 'new' statments, not everyplace the calls are made.

      • "future-proofing" - as the user gains sophisitication, he or she can more easily modify the modules, or create new ones that inherit from the existing. Exporting or fully qualifying can defeat that.

      • "future-proofing" - on the day when the user suddenly wants to set instance data for his routines, he or she is ready.

      Besides, fully qualified calls just look ugly to me, though I suppose it's safer than trusting multiple modules not to stomp on each other or your own functions. Using object methods are also fully qualified.

      --Bob Niederman, http://bob-n.com

      All code given here is UNTESTED unless otherwise stated.

[reply]

In Section Seekers of Perl Wisdom