Re^7: can't import using exporter

Extraordinary claims require extraordinary evidence.

So far, all you have shown are two snippets that don't compile and a huge program that you obviously did not care to cut down to the problem. I've reduced your program to the following, self-contained program and noted where I added BEGIN blocks to make all symbols appear in the order which use would make appear them in as well:

#!/usr/bin/perl -w
use 5.12.0;
use warnings FATAL => 'all';

BEGIN { # Added this because that's how "use" works
package Debug;{ 
    use Exporter 'import';
    our @EXPORT=qw( Debug $Filename2Fields);
    
    
    my %dop = (
            Filename2Fields    =>    1,
            HaltOnError            =>    2,
    );

    our $Filename2Fields= $dop{Filename2Fields};
    our $HaltOnError    = $dop{HaltOnError};
    sub Debug($$) {
            my ($what,  $str)=@_;
            print STDERR $str;
    }
};
}

BEGIN { # Added this because that's how "use" works
package Transcode_plug;{
    use strict;
    use Exporter 'import';
    BEGIN { Debug->import() };
    our @EXPORT=qw( album get_fieldAR_from_filename ); 
    
    sub album {};

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

package main;
BEGIN {
    Transcode_plug->import;
};
print "Main is running\n";

# Now see that even prototype parsing works properly:

print "OK\n";

get_fieldAR_from_filename "Foo";

# vim: ts=2 sw=2
[download]

It behooves you well to put more effort into making your findings reproducible, especially when nobody else seems to be able to reproduce your problem.

Also, you may be interested in App::fatpacker, which packs a script and its modules into one monolithic file.

Comment on Re^7: can't import using exporter Download Code

Replies are listed 'Best First'.
Fixed a year later... by perl-diddler (Chaplain) on Mar 25, 2013 at 17:54 UTC
The above, today would be written more naturally, like: #!/usr/bin/perl -w { package Debug; use warnings; use strict; our (@ISA,@EXPORT,$DBGOPS); use mem; use mem(@ISA=qw(Exporter), @EXPORT=qw( Debug Filename2Fields HaltOnE +rror); use Exporter; use P; use constant Filename2Fields => 1; use constant HaltOnError => Filename2Fields << 1; sub Debug($$;@) { shift & $DBGOPS && Pe shift,@_ } 1}; ################################################### { package Transcode_plug; use warnings; use strict; our (@ISA, @EXPORT); use mem; use mem(@ISA=qw(Exporter), @EXPORT=qw( album get_fieldAR_from_filena +me); use Exporter; use Debug; sub album() {$_[0]->}; sub get_fieldAR_from_filename($) { Debug(Filename2Fields, "get_fieldAR_from_filename(%s)", $_[0]); } 1} ##################################################### package main; use Transcode_plug; use P; P "Main is running"; # Now see that even prototype parsing works properly: P "OK"; get_fieldAR_from_filename "Foo"; [download] No BEGIN's in sight, and a natural 'use module' syntax the same as one would use them if they were in separate files. A few other things would be simpler as well, but they aren't in a form to be published yet... I do learn... using mem with Exporter as I did above, also exports the prototypes. May not be perfect, but looks tidier than using BEGIN blocks and the modules have the benefit of being easily put into separate files with no code changes. Better?	[reply] [d/l]
Re: Fixed a year later... by tobyink (Canon) on Mar 26, 2013 at 09:54 UTC
Personally I'd do this: `use strict; use warnings; BEGIN { package MyUtils; no thanks; use base "Exporter"; our @EXPORT = "shout"; sub shout { print @_, "!!!\n"; } 1; }; use MyUtils; shout "it works";` [download] I don't have any problem with the `BEGIN` block. I'd always wrap inline packages in braces anyway, so it's just five extra letters before the opening brace. If I want to factor out MyUtils into a separate file, it's just a matter of cutting everything inside the braces and pasting it into MyUtils.pm; then replace the now empty `BEGIN {}` block with `use MyUtils;`. Easy. (And if I was being a perfectionist, I could remove `no thanks;` from MyUtils.pm as it becomes superfluous.) `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply] [d/l] [select]
Re^2: Fixed a year later... by perl-diddler (Chaplain) on Mar 27, 2013 at 23:24 UTC
To each their own. When I see a BEGIN block, it interrupts the structure of the code. Also I find a need to re-use strict & warnings inside of different packages. I tend to use alot of packages in writing programs as a means to create typed-classes. I.e. if I need a structure, I want a type for it and that usually means a class/package. But for most data types/structures, I wouldn't see them getting large enough or important enough to split into separate files. Most of my code writing was in C -- and I liked typedefs and structures for grouping data. But one virtually never thinks of putting each typedef and structure into a separate file. One also doesn't like seeing lots of #if/#define/#else#endif's in C-code as they disrupt the normal indentation and the visual flow of the code. I like to see the look of the code reflect its function and having an ALLCAPS standoff block just doesn't look attractive. It highlights something unimportant -- that you need to make sure your defines are executed in phase1 of the perl interpreter, in order that they work in phase2. To me, users shouldn't have to think about those things -- they should just 'work'. So rather than having my attention drawn to quirks specific to perl, I can focus my attention on the underlying algorithm. Using BEGIN or referencing $INC{xxx}, takes my attention away from the underlying algorithm and makes focusing on it more difficult. But that's a quirk of my programming! ;-) Someone on a list recently said they WANTED their usage of quirks to stand out... ouch... to me, those are things to gloss over, not emphasize. Oh well, as I said, to each their own...	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.