Unless you really need the lazy evaluation, memoization, and what-not, you could use Want directly. Want is the module that Contextual::Return uses to figure out the context. Here's an example:

use Want;

sub funner {
    if (want('LIST')) {
        return qw/Larry Curly Moe/;
    }
    elsif (want('ARRAY')) {
        return [ qw/Larry Curly Moe/ ];
    }
    else {
        croak("listy type contexts only");
    }
}

print Dumper [ funner() ];
print Dumper [ @{funner()} ];
funner();

__END__
$VAR1 = [
          'Larry',
          'Curly',
          'Moe'
        ];
$VAR1 = [
          'Larry',
          'Curly',
          'Moe'
        ];
listy type contexts only at ...
[download]

lodin

I haven't tested it, but I suspect that making a change like this might help:

If you're not getting the imports, you're not getting their prototypes and you have to be slightly more explicit.

That actually does properly return qw/Larry Curly Moe/ if called in a LIST context but it doesn't permit me to have more than one return context.

• If I add another one, Contextual::Return::SCALAR( sub{ 3 }), I get a syntax error.
• If I || those two conditions on the same line (thinking if the first fails, I'll get the SCALAR context), I get told that "main::funner() cannot be called in boolean context".
• If I call funner() in a scalar context when I just have only have the LIST contextual return clause i get this out of Data::Dumper:

$VAR1 = {
          'result' => bless( do{\(my $o = undef)}, 'Contextual::Return
+::Value' )
        };
[download]

So it seems you're closer... but it's still a breakin'.

--
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`
[download]

M-x Visit Tags Table
M-x Tags-Query-Replace
[download]

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

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