UPDATE
Oops, I misread the question. Your problem is not what you think it is. It is an order of action issue. Here is the order of actions with the section commented out:

1. Start your script.
2. Go off and load the module.
3. import from the module.
4. Compile the rest of the script, including overwriting the function.
5. Execute the script, calling the function. (Get the local version.)

1. Start your script.
2. Go off and load the module.
3. import from the module.
4. Compile the rest of the script, including overwriting the function.
5. Manually import the function again, overwriting the local function.
6. Execute the script, calling the function. (Get the module version.)

The answer is that you can't. But if you move the use to the *end* of the script you will get the module version. If you manually call import in your script you will likewise be able to get the module version. However you cannot prevent the code using the module from being able to overwrite what you exported. Which is really how it should be. Module authors should not be deliberately equipped with weapons to allow their bad assumptions to accidentally cause hard-to-fix grief for users of their code.

Ahhh, very enlightening.... You are correct. Moving use My::Module qw(testsub) to the end, or calling My::Module->import(qw(testsub)) both seem to give me the behaviour I wanted.

I'll have to recheck my example to see if it also applies to the mod_perl issues I'm having.

I understand your caveat, but in my mod_perl development environment the exported subroutine is simply clobbering an older version of itself. I'm essentially just trying to un-cache the subroutine after it gets modified on disk.

Thanks.
-Blake

Update:

This does solve my mod_perl problem. The difference between the following two lines is the key.
1. use My::Module qw(testsub);
2. use My::Module; My::Module->import(qw(testsub));

#1 imports when the module is loaded, #2 imports at runtime. thanks again.

-Blake

undef testsub();
sub testsub { eval 'whatever action you want to take' }
[download]

Problem: Changes to modules aren't seen by mod_perl / mason / apache without an explicit 'apacheclt restart'

Solution First see Apache::Reload. This will solve most cases, except for certain exporting issues. use My::Module qw(testsub); still seems to be using the old version of testsub().
Rewrite the above line to read. use My::Module; My::Module->import(qw(testsub)); which in conjunction with Apache::Reload should fix the problem. All scripts/pages should now see the new subroutine.

---- My::Module.pm ----

package My::Module;
BEGIN {
  use Exporter ();
  use vars qw(@ISA @EXPORT @EXPORT_OK);
  @ISA       = qw(Exporter);
  @EXPORT    = qw();
  @EXPORT_OK = qw(testsub);
}
use strict;
use Apache::Reload;

sub testsub {
    return "module subroutine";
}
1;
[download]

#!/usr/bin/perl
use My::Module;
My::Module->import(qw(testsub));

print testsub(), "\n";

sub testsub { # "local" definition of subroutine
    return "local subroutine";
}
[download]

<% $txt %>
<%INIT>
use My::Module;
My::Module->import(qw(testsub));
my $txt = testsub();
</%INIT>
[download]

PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
[download]

use Apache::Reload;
[download]

-Blake

Use it like this:

use ForceExport;  # hypothetical
use My::Module 'testsub';
no ForseExport;  # put it back the way it was.
[download]

This will not and cannot work.

See my update explaining what the problem really is (now that I read the question properly.)

I actually tried defining my own import function (My::Module::import) before I posted. It didn't work the way I had hoped. Thanks though.

-Blake