To quote your own code: '.&unknown_type' => sub { Err "import parameter is not a string" }, So I think you have yourself to blame. (:

I have used non-strings in import routines with no such problems.

Thanks. I'll have to figure out why it's still in there instead of being stripped earlier.

I think I'll also prefix my error messages with something unique to avoid such confusion. The line number info on the error isn't always helpful I guess especially in the wee hours of the morning!

Thanks for looking it over.

—John

Eh? I ran this test and it seems to allow hashrefs just fine. I haven't looked at your scratchpad yet, though.

[johnsca@CORY tmp]$ cat tst.pm
#!/usr/bin/perl

package tst;

use warnings;
use strict;

sub import {
  my $self = shift;
  my $hr   = shift;
  print "foo: `$hr->{foo}'\n";
}

1;
[johnsca@CORY tmp]$ cat tst
#!/usr/bin/perl

use warnings;

use lib '.';
use tst { foo => 'bar' };
[johnsca@CORY tmp]$ ./tst
foo: `bar'
[download]

P.S. The link to your scratchpad doesn't work with the underscores.

Update: Yes, as tye points out, the error message is coming from your Exporter::VA module. I can't seem to find, in the code on your scratchpad, where you define the handler for the hashref to your module's (Exporter::VA's) import.

Update2: I found it, in find_export_def(). A lot of indirection going on in that module. I'm still working out where find_export_def() is called from.

Update3:Well, it looks like the whole problem is that find_export_def() isn't called, because export_import() is never called. It looks like you're exporting &export_import as the import routine that the user of the module will get, when you should be using it as your import routine and exporting the results of generate_import() (which is what you're actually using as your import routine). Um, or something?

bbfu
Black flowers blossum
Fearless on my breath

re update 3: I think if Module were importing &export_import instead of the result of generate_import, then nothing would work. The notation in the %EXPORT definition triggers this as a callback, not a hard link. So when Module imports import, it will call export_import and take the result of that call as the symbol to put in &Module::import.

A lot of indirection: Yea, this module provides an import function to your module, which is then used by the client. Importing from Exporter::VA to Module is the same process as exporting from Module to Client. It's easy to get meta-levels confused. But I think it's wonderfully elegant.

Thanks for looking it over. Any other critical comments on the code or POD?

—John

Found it: The line

 my $client_export_def= bless find_export_def ($caller, $param_list_ta
+il), "Exporter::VA";
[download]

was passing @_ instead of $param_list_tail to the find_export_def function. So it never found and removed it in the first place, and the error came later on as tye points out.

That's what testing is for, especially in a language that doesn't find much at "compile time" like some others.