in reply to Re^19: can't import using exporter
in thread can't import using exporter

I'm not sure I get your point.

I'm not sure if you are trying to point at a solution or what?

Does Exporter not work for variable names in 6.14? It's documented as supporting them in its pod/manpages, but putting the var in @EXPORT as '$var' and then importing it in another package, doesn't work either in 6.14.

Does it work in your 5.8? 

package Debug;
{use parent "Exporter";
our $var="foo";
our @EXPORT=qw($foo);
}
package main;
{import Debug;

print $var;
}'
Name "main::var" used only once: possible typo at -e line 10.
Use of uninitialized value $var in print at -e line 10.

[download]

Replies are listed 'Best First'.
Re^21: can't import using exporter
by chromatic (Archbishop) on Mar 24, 2012 at 17:27 UTC
    Does it work in your 5.8?

    As you've written it, of course it doesn't work.

[reply]
      I wondered why I got an extra warning in the cut down version...

      but that's what I get for cuttin down.... can't type straight. ;-)

      ok so export var and not it's contents...

      I get warning, but it appears to work.

      Ok... but that's what I have in the larger program. But that's not the error it puts out... 

      > less testme.pl
#!/usr/bin/perl -w
use strict;
package _Debug;{ 
  our $Filename2Fields  = 1;
  our $HaltOnError      = 2;
  our $DEBUG_OPS        = 3;
  our @EXPORT=qw( Debug $DEBUG_OPS $Filename2Fields $Halt_on_Error);
  use parent 'Exporter';
  sub Debug($$) { my ($what,  $str)=@_;
    if ($what & $DEBUG_OPS) { print STDERR $str; } } }

package Transcode_plug;{
  import _Debug; 
  sub get_fieldAR_from_filename($) {
    my $file=$_[0];
    Debug($Filename2Fields,"get_fieldAR_from_filename($file)\n");
  }
}

Transcode_plug::get_fieldAR_from_filename('dummy');
# vim: ts=2 sw=2
Ishtar:/Audio/scripts> testme.pl
Global symbol "$Filename2Fields" requires explicit package name at ./t
+estme.pl line 16.
Execution of ./testme.pl aborted due to compilation errors.

      [download]

      But if I turn off strict and turn off warnings, it runs just fine.

      *cough*.

      How is this not a bug in perl 5.14? Crying wolf is bad, we learned that in grade school.

[reply]
[d/l]
        How is this not a bug in perl 5.14?

        Because it's your bug. As I said in my first response, things aren't happening when you think they're happening. If you put your code in separate files and used them, you wouldn't have this problem.

        The strict check happens at the end of compilation. Your import call hasn't happened yet, so of course the importing of your variable hasn't happened yet.

        Throw a BEGIN block around that import and strict will still complain because nothing gets imported because the assignment to @EXPORT hasn't happened yet.

        Throw a BEGIN block around that assignment and you'll finally get things to start to work. You'll have a mess on your hands, because you'll have to juggle the details of when things happen and in which order and why, especially with everything jumbled together in the same file.

        That's why the rest of us use separate files and let use manage all of those details for us. It's not complicated. It's not working around bugs in Perl (you have the same problem with every version of Perl 5 I've ever used). It's knowing what happens when and why and letting the computer worry about that. Having to rearrange code to get the order of declarations right wasn't fun in Pascal (and almost 45 years later, computer science has moved on.)

[reply]
[d/l]
[select]

        How is this not a bug in perl 5.14?

        A poor workman blames his tools

[reply]

In Section Seekers of Perl Wisdom