Trust me, I didn't miss it :-) I agree entirely that it's a judgement call whether to export/import functions, I just didn't make that judgement explicit in the previous post.

So, to be explicit: I very, very rarely use non-class/object methods in my code. So the only areas where I find exporting/importing to be an issue are CPAN modules that export functions: File::Find, File::Path, etc. My reason for this is simple: many of these modules export very generic function names ('find', 'mkpath', etc.), and I find it more instructive to see:

  my $user_dir = File::Basename::dirname( $user_file );
[download]

versus:

   my $user_dir = dirname( $user_file );
[download]

If something goes wrong, the second one will have me looking around for sub dirname{}, the first one won't because it's a trusted source. (Then again, you could say that all libraries should be trusted sources -- to that I'd say, depending on the module, I'd trust others before myself :-)

Again, this is two ways of doing the same thing. Instead of exporting a function I use a class or object. So instead of:

  use MyModule qw( myfunc );

  my $result = myfunc( \%args );
[download]

I'd do:

  use MyModule;

  my $result = MyModule->myfunc( \%args );
[download]

What 'MyModule' does behind the scenes can be modified without the user ever knowing -- it could be transformed from a simple function to a factory method that creates an object behind the scenes based on \%args or the environment, whatever. And it opens up the possibility for a design where state needs to be maintained between invocations. It's easy to change this to:

  use MyModule;

  my $thingy = MyModule->new( \%args )
  my $result1 = $thingy->myfunc( \%overriding_args1 );
  my $result2 = $thingy->myfunc( \%overriding_args2 );
[download]

So: TMTOWTDI :-)

Chris
M-x auto-bs-mode