in reply to Why doesn't @EXPORT = (keys %METHODS) 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;

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.

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

Replies are listed 'Best First'.
Re (tilly) 2: Why doesn't @EXPORT = (keys %METHODS) work?
by tilly (Archbishop) on Mar 17, 2001 at 18:22 UTC
    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;
      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")
        Obviously I wouldn't advocate obvious mistakes. For this code my preference would look something like this:
        package Example; use Exporter; @ISA = 'Exporter'; $VERSION = 1.02; use strict; use vars qw(@EXPORT_OK); my %METHODS = ( foo => 'bar', bo => 'baz', ); @EXPORT_OK = (keys %METHODS); foreach my $method (keys %METHODS) { no strict 'refs'; *$method = sub { return $METHODS{ $method }; }; } 1;
        Move strict after all bog standard headers, but leave it before any complex logic. And, of course, where you need to, remove it. In this case 2 of 3 variables didn't need to be declared.

        As for your objection about needing to use it, if you actually need to use it (as here) then of course it goes into a vars. But I find that 90% of the time the standard variables that you need for inheritance, Exporter, and versioning really shouldn't appear a second time. I see no need to spend effort making it possible unless I need to. And note the detail that if you have a typo on these standard variables, then warnings will catch it. So spelling isn't an issue.

        As for the stupid mistakes that you refer to, we went through that before and there was not one you could find that I agreed on. Basically my attitude is that if you get in the habit of not playing unnecessarily cute games, then those mistakes don't happen. Plus your games wind up confusing other tools, like Carp. Trying to counteract one trick with another is something that I prefer to avoid.