# Usage: unalias ($package, $name)
# Will remove the subroutine entry from the package's glob
sub unalias {
    my ($package, $name) = @_;
    no strict;    # Disable the safety systems
    local *temp;  # Make a local glob
    
    my $glob = ${"${package}::"}{$name};  # Grab the glob
    *temp = *$glob{SCALAR};    # Copy the scalar part
    *temp = *$glob{ARRAY}  if defined *$glob{ARRAY};
    *temp = *$glob{HASH}   if defined *$glob{HASH};
    *temp = *$glob{IO}     if defined *$glob{IO};
    *temp = *$glob{FORMAT} if defined *$glob{FORMAT};
    
    ${"${package}::"}{$name} = *temp;
}
[download]

Very cool. That works. Assign everything but the piece you don't want. That's one I didn't try. And it's so obvious once you see it.

Since you solved that one, how about the bigger question that started me down this path: When a module's VERSION method is called, is there a way to stop compilation of the module at that point and switch to another one? This all started with an experimental piece of code like this:

use Carp;

sub UNIVERSAL::VERSION
{
    my $class          = shift;
    my $wanted_version = shift;
    my $fixed_version  = $wanted_version;
    my $caller         = caller();
    my $version_class;

    $fixed_version =~ s/\./_/g;
    $version_class = "${class}_${fixed_version}";

    eval <<"END_EVAL";

    package $caller;
    no $class;
    require $version_class;
    $version_class->import();

END_EVAL

    croak "Version $wanted_version of $class not found ($version_class
+): $@"
      if ($@);
}
[download]

I believe this works because the eval code runs after the BEGIN code (from use) that invoked the VERSION method. So the versioned copy of the module loads after, overwriting aliases. But ideally I'd want to just stop compilation of the non-versioned module so there are no BEGIN, CHECK, END type blocks pulled in.

Thanks for the help on the one above. Most people I start talking typeglobs and symbol tables to just glaze over.

Sadly, it's impossible to stop compilation of the module from a VERSION sub, because the module has already been compiled before the VERSION sub is invoked! You can check that by writing a BEGIN block which prints something -- you'll see that the BEGIN block is called before the VERSION sub.

If you think about it, it has to be done that way. The module needs to be compiled first, otherwise the import() and VERSION() subs wouldn't be defined. Even though CHECK blocks are called later, it's still too late to stop them either: when a CHECK block is compiled, it's added to an internal list of routines to call at the end of compile time, and there's no way to modify that list without writing some hairy C code.

If you have my Want module installed, you can stop the module use process dead from within the VERSION method: There's an undocumented internal routine Want::double_return which diddles perl's internal data structures so that when you return from the sub you're in, the sub that called you immediately returns as well. So if your VERSION routine contains:

  use Want ();
  Want::double_return();
  return;
[download]

then the use process will be stopped right there, and the import routine will never be called. Unfortunately that still won't stop BEGIN or CHECK blocks, and anyway it's rather too much like black magic for everyday use. Fun though :-)

That's not a bad module idea, requiring a certain version or version range of a module, provided you have several installed. Anyone want to write it, or did I just volunteer?

Maybe. I already have something that lets me look in alternate @INC paths for modules under development. This one was intended to allow me to not have to worry about copying that full directory hierarchy (most of our modules hang in a 3 deep path). Instead I wanted to just copy files in the same working directory and have development test code specify the next highest version. I'd test like that, then copy the new version of the file to the "current" one when done, saving the old one under an old version (at least for a while) Anything other than the current version would be file named by using a version suffix. That would allow for a pretty unlimited versioning development path (I think) without requiring new include paths. I'm probably missing other pieces though -- I just set up that small bit of test code so far.

The current module (one with the normal file name) is thus acting as the master. If someone asks to use a version other than the one it is, it would go out and try to substitute that version. That's where I'd like to stop compilation of the master file and switch over to the alternate version instead. All the unaliasing tests (useful in their own right) were the result of not being able to stop compilation of the master while continuing compilation of the alternate. Instead I let the master complete, I unalias all its imports, then compile the alternate version. As mentioned, this won't handle changes to BEGIN, END, CHECK style blocks across versions.

Maybe hanging this off the call to the VERSION method has led me down the wrong path here though.

More ideas welcome ...