Partial success - hijacking a module constructor

[hackmare]

Thanks for the help and insight, Tilly.

Sorry about the slow reply. I was up to my ears trying to figure this out.

I also got your idea passed on at the London Perl Mongers mailing list, and it partly works: I can re-map the GD::Image to use SVG::Image.

And yes, you're absolutely right about the re-writing at load time. This is what makes this work *at all*. But only if it is loaded *after* GD is loaded.

BEGIN {
    *GD::Image:: = *SVG::GD::Image::;
}

However, I'm now in an all-new kind of problem...

I would have thought that the following:

BEGIN {
    *SVG::H:: = *GD::
    *GD::Image:: = *SVG::GD::Image::;
}

would have also given me a working access to the GD module so that my constructor could do this:

SVG::GD::Image::new {
   ....create object and bless... as $self
   $self->{_GD_} = SVG::H::Image::new()
}

Unfortunately this does not seem to be the case, though.

It looks like when I do this then the SVG::H:: namespace *also* gets reassigned to the SVG::GD::Image namespace. Most wierd. So I tried a second alternative... I mapped every method in GD.pm to SVG::H::GD like this:

 *SVG::H::GD::Image::new = \&GD::Image::new;
 *SVG::H::GD::Image::meths = \&GD::Image::meths;

And this time, things get even worse. The module fails to bring in the xs module _new of (apparently correct) invocation. Apparently xs I need to manipulate the xs calls as well? Here, I'm lost. Maybe I need to re-map the xs methods too...:

 *SVG::H::GD::_new = \&GD::_new;
 ...etc for every xs subroutine...

If you are interested in the actual code to take a look at it, it's the SVG::GD module on CPAN (0.7). I'm trying to implement a GD from within the constructor and failed + had to give up.

Thanks for the help... Couldn't have gotten this far without outside help. I'm hoping that SVG::GD module will breathe some new life into GD if I can get the wrinkles out.

If you have any interest at seeing the result of the first cut of my attempt to highjack GD, here's a test page with some output from GD.pm, GD::Graph.*, and some bioperl GD output:

GD Test output to SVG all the GD examples I could compile with SVG::GD

bioperl output test to SVG via GD A test of a bioperl graphic trying to see how bioperl can handle it (they were looking for GD support a while back). bioperl is a real stress test because it handles the GD constructor wayyyy down the module dependency tree.

Ronan.