But the main problem is that you need to set up your %METHODS hash in the BEGIN block, so that it gets initialized *before* you try to use it. Ie.:

    my(%METHODS);
    our @EXPORT;

    BEGIN {
        %METHODS = (
            foo => 'bar',
            bo  => 'baz',
        );

        @EXPORT = keys %METHODS;

        foreach my $method (keys %METHODS) {
            no strict 'refs';
            *$methods = sub {
                return $METHODS{ $method };
            };
        }
    }
[download]

To my eyes moving more into BEGIN is solving one mistake by making another. Just lose the BEGIN block entirely and (as merlyn pointed out) don't mess up your populating the array and hash. Also avoid the $method/$methods typo that you have.

It will work just fine. After all from the point of view of the place where you are being used from, you already ARE in a BEGIN block...

Looks like the culprit, though how does this square with the claim "The dynamic methods are generated with no problem"?

I suspect that there's more going here than meets the eye. Seeing the complete script might shed more light.

You really need to use strict; here.

Sadly, it's legal syntax, although fatal under use strict qw(subs).

It's %keys (the hash) mod METHODS.

{grin}

-- Randal L. Schwartz, Perl hacker

Actually, that's my typo in entering it in Perl monks (see above). I already use struct, and it still doesn't work.

I used the following code to test (fixed your typos -- shame on you):

package Fred;

use strict;
require Exporter;
our @ISA = qw( Exporter );

our %EXPORT_TAGS = ( 'all' => [ qw( ) ] );
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );

my %METHODS = (
  foo => 'bar',
  bo  => 'baz',
);

our @EXPORT = (keys %METHODS);

BEGIN {
  foreach my $method (keys %METHODS) {
    no strict 'refs';
    *$method = sub {
      return $METHODS{ $method };
    };
  }
}

1;
[download]

The dynamic methods are generated with no problem, but it seems @EXPORT doesn't contain these values.

I get the exact opposite behavior. @EXPORT gets populated but no dynamic methods are defined. I think you need to reexamine how you are coming to your conclusions and post an exact minimal script that produces the problem rather than typing in what you think is causing the problem.

One fix is to simply remove "BEGIN {" and "}". All of your our initializations are happening at run time so it doesn't make sense to do that last block at compile time.

Personally, I'd probably ditch our in favor of use vars and move all of the initializations into one BEGIN block.

As we have discussed, I would ditch both our and vars and just move the strict to after the standard initializations. As we also discussed, I would not use a BEGIN block at all...

I don't recall having actually discussed your "move use strict" idea before. For this code, would it look something like this?

package Fred;

require Exporter;
@ISA = qw( Exportor );
$VERSION = 1.01;

%EXPORT_TAGS = ( 'all' => [ qw( ) ] );
@EXPORT_OK = ( @{ $EXPORT_TAG{'all'} } );

my %METHODS = (
  foo => 'bar',
  bo  => 'baz',
);

@EXPORT = (keys %METHOD);

use strict;

foreach my $method (keys %METHODS) {
    *$method = sub {
        return $METHODS{ $method };
    };
}

die "Use of ", __PACKAGE__, " (v$VERSION) not supported.\n"
    if  ! prerequisites();

1;
[download]

Note that the above code contains several mistakes but the only complaint you'll get from Perl will be a fatal error for one thing that isn't a mistake. (Hmm, I would have thought that having warnings enabled would have given you a warning about one of the real mistakes, but my testing shows otherwise.)

I guess your idea might make sense if you only ever mention each variable exactly once (the "standard" variables appear to be exempt from the "used only once" warning, so there is one more thing to worry about if you try this trick when you need any nonstandard package variables). But I still don't consider it a sound design as it is too easy to imagine future changes resulting in some of the variables actually being used within the package.

And if you use the variable as part of a standard initialization (above the use strict), then your typos are not caught. If you use the variable below the use strict, then you get a fatal compile-time error.

Note that I did suggest just removing the BEGIN block before I mentioned my personal preference, which I find makes things more robust in the face of several kinds of stupid mistakes. Not that I want to encourage such mistakes. It is just that the failure modes of those mistakes don't clearly point a finger at the mistake. Otherwise I think I'd stop that habit.

        - tye (but my friends call me "Tye")