in reply to lazily getting around an Exporter problem

Gentle meraxes,

You apparently have already tried to stop Contextual::Return from exporting SCALAR ARRAYREF HASHREF and that breaks something mysterious, right?

Ok, here are several lazy hacks that I'd try. I am a monk assuredly more foolish and confused than many. Due to my ignorance, they are unlikely to work, but some helpful monk may explain to me why not, and thus I will profit.

Vandalism: I'd fire up EMACS on all the .pl / .pm files in Contextual::Return. I'd replace every occurence of
SCALAR => SCALARdangit
ARRAYREF => ARRAYREFdangit
HASHREF => HASHREFdangit,
and try the MAKE again.

I'm assuming you have EMACS. No doubt someone else can supply the method for vi. (You could also do this with a perl script, or maybe even a single command line, but not me.) To invoke Tags Query Replace, you first create a tag-table. Go to the directory where you put Contextual::Return

% etags `find . -name '*.p[lm]' -print`
which creates a TAGS file. Go into emacs and command
M-x Visit Tags Table M-x Tags-Query-Replace
Do the replace three times, changing each of the offending variables. Default is that this replace is case sensitive. Save all changed files (c-x s).

After I'd given up on that approach, I'd try
Stealth: I'd create a dummy module, with its own package, that used Contextual::Return. The only things I'd export out of it would be the specific Contextual::Return functions that I needed, not including SCALAR ARRAYREF HASHREF. Then I'd use that dummy module in my main module.

throop

Replies are listed 'Best First'.
Re^2: lazily getting around an Exporter problem
by meraxes (Friar) on Oct 04, 2007 at 22:00 UTC

    Thankee, but I don't think these are the approaches for me.

    The first, manually changing the module means I can't update it from CPAN anymore without having to reapply my changes. As the App I'm working on is deployed on multiple boxes, this isn't a solution that would we welcomed into the deployment process. It would also break any other modules that depend on it. I suppose I could RENAME the module to something else and do as you say to avoid the dependency problem, but I'd still be stuck manually caring for the module should it be patched.

    The second is problematic as well. I need the function I'm doing to be in the same namespace as it's an OO module and needs access to $self. I could manually pass $self into the function, but it wouldn't be a particularly good way out of this problem.

    Many thanks for the suggestions though.

    --
    meraxes