in reply to Re: Re: Re: Re: Re: hijacking a module constructor
in thread hijacking a module constructor
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:
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::Image::new = \&GD::Image::new; *SVG::H::GD::Image::meths = \&GD::Image::meths;
*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.