This is just a thought about how to get around some of the problems listed in Getting Fed Up with ActiveState. However, it might have a more general purpose use, even though the thought gives me the willies.

Let's say that you need to use a particular function out of a module but the module won't compile on your system or, in the case of ActiveState, it's a core module you can't upgrade to the latest version. In the former case, maybe you only need to reimplement one function. In the case of the latter, maybe you can't find a PPM for it or (as in some cases), trying to explain to myriad users how to use a different repository is difficult. It might be nice to have a standard mechanism to work around this. Here's on thought, though I confess I'm not terribly happy with this.

use Module::Substitute
  'Scalar::Util' => [qw/refaddr openhandle/];

print refaddr $some_object;
[download]

Of course, the devil is in the details, but here's a quick implementation/hack of this:

package Module::Substitute;

use warnings;
use strict;
use Data::Dumper;

our $VERSION = '0.01';

sub import {
    my $class = shift;
    my $calling_package = caller(0);
    my %module = @_;

    while ( my ($module, $import_list) = each %module ) {
        local $Data::Dumper::Terse = 1;
        
        $import_list = [$import_list]
          unless 'ARRAY' eq ref $import_list;
        my $imports = Dumper($import_list);
        $imports =~ s/^\[|\]$//g;

        my $substitute = __PACKAGE__ . "::$module";
        
        eval <<"        END_IMPORT";
        package $calling_package;
        
        use $substitute $imports;
        END_IMPORT
        if ( my $error = $@ ) {
            _croak("Could not substitute ($module): $error");
        }
    }
} 

sub _croak {
    my $message = shift;
    require Carp;
    $Carp::CarpLevel = 1;
    Carp::croak($message);
}

1;
[download]

With that, you'd set up a Module::Substitute::Scalar::Util which allows the functions to be exported. So far the above code seems to work fine in my initial tests.

Downsides: this has the obvious problem that we'd be likely to duplicate code and for every author willing to provide a Module::Substitute::Some::Other::Module package, they'd have to keep it in synch with the original package. This could be a serious problem.

Advantages: currently, authors who use features of upgraded core modules have a good chance of those failing the ActiveState build process. For example, consider the Scalar::Util::refaddr mentioned listed above. Since I use CPAN::Mini, I was able to use schwern's grep_cpan to search for modules which used refaddr (this was a naive check which didn't take into account that someone might be using a different function with the same name). After a bit of massaging the output and using a hack with HTML::TableExtract and LWP, I was able to list which of those modules were able to be built on Windows by ActiveState. My results?

Failed 95
Passed 9

Here's a quick sample of some of those modules:

• Archive::Builder
• Archive::Zip
• Array::AsHash
• Astro::satpass
• Business::Bof::Client
• Business::Bof::Server
• Catalyst::Plugin::Cache
• CGI::Application::Plugin::Authentication
• CGI::Application::Plugin::Authorization
• CGI::Session
• Class::Adapter
• Class::Autouse
• Class::BuildMethods
• Class::Constant
• Class::DBI
• Class::DBI::Sweet
• Class::InsideOut
• Class::MOP
• Class::Simple
• Class::StateMachine

I'm sure many of you have used a few of those. Do you really want them to not be available via PPM? If they're only failing because of refaddr, my proposal, though it requires code duplication, could potentially allow them to be available.

A cursory check of the nine which passed suggested that some were not directly importing refaddr from Scalar::Util but were instead relying on the fully-qualified function name and their test suites were not sufficiently robust enough to detect that whether it was available.

Frankly, I don't like my suggestion, but I'm trying to figure out a way around this problem and other suggestions would be welcome.