Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^22: can't import using exporter

by perl-diddler (Hermit)
on Mar 24, 2012 at 22:29 UTC ( #961442=note: print w/ replies, xml ) Need Help??


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

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.

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.


Comment on Re^22: can't import using exporter
Download Code
Re^23: can't import using exporter
by Anonymous Monk on Mar 25, 2012 at 07:23 UTC

    How is this not a bug in perl 5.14?

    A poor workman blames his tools

      In this case it would be better to say it is a good crafter who knows their tools. Not knowing the flaws or weaknesses of ones tools would be the fault of the crafter.

        In this case it would be better to say it is a good crafter who knows their tools. Not knowing the flaws or weaknesses of ones tools would be the fault of the crafter.

        Ok, perl-diddler blames his tools for not knowing how to use them.

        perl-diddler blames brian_d_foy and merlyn for teaching him.

Re^23: can't import using exporter
by chromatic (Archbishop) on Mar 25, 2012 at 07:30 UTC
    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.)

      No, it's not my bug... it's a design failure in the language.

      It is not said in the expert books on perl that you *must* put things in separate files. That's a made up requirement by people who didn't know or don't know how to call a bug a bug or work around it.

      Fortunately, newer language constructs like 'use base' which says:

      "base" employs some heuristics to determine if a module has already been loaded, if it has it doesn't try again. If "base" tries to "require" the module it will not die if it cannot find the modu +le's file, but will die on any other error. After all this, should y +our base class be empty, containing no symbols, it will die. This is use +ful for inheriting from classes in the same file as yourself, like so:
      Now if you HVE to put things in separate files, why would could be going into the base that is specifically designed for when things aren't in separate files -- Why? Because perl wasn't designed to have the requirement that different classes be developed in separate files.

      The fact that this does not work:

      #!/usr/bin/perl -w use strict; package pkg; { our $var="foo"; our @EXPORT=qw($var); use Exporter qw(import); } package main; use strict; use warnings; import pkg; BEGIN { *var=\$pkg::var;} print "var=$var\n";
      Is a bug in perl.

      I try multiple ways, above to import that var. None of them work.

      That doesn't mean you couldn't write various parts in BEGIN, but none of the introductory books written by the language authors say you should use BEGIN or separate files. To me -- that indicates that BEGIN's and separate files should tend toward being a more advanced topic -- while development of programs in 1 file should be considered the norm -- unless you want to break out functionality for use with other programs.

      You shouldn't need to break apart a program if you are not trying to make libraries and if the program isn't getting "too long".

      What is too long?

      Taking perl as an example -- there are 147 "c" files in the 5.14.2 dist w/a total of 217508 lines. That's an average of 1500 lines/file. Most are small fails, but the meat of the main program is in large files.

      In other projects 1500-3000 is not atypical for a single program -- with smaller files usually being library functions.

      That people should think that breaking apart programs into little files is 'normal', goes against the norms of other languages.

      I'm not certain, but I **think** (not sure) the only other language that might have such a similar requirement is 'java', the "Cobol" of the Web age.

      I wouldn't call that a positive selling point.

        ... none of the introductory books written by the language authors say you should use BEGIN or separate files.

        See the final two paragraphs on page 128 of the third edition of the Camel as well as pages 302 and 303. See also page 294.

        I try multiple ways, above to import that var. None of them work.

        Several given in this thread work.

        Because perl wasn't designed to have the requirement that different classes be developed in separate files.

        Non sequitur. Perl wasn't designed for you to call import() directly yourself. When you mix several different concepts together without understanding how Perl works, you get the mess you have.

        Feel free to file this as a bug with p5p. You'll get the same answer there.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://961442]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2014-08-20 19:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (122 votes), past polls