Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^7: can't import using exporter

by Corion (Pope)
on Mar 14, 2012 at 08:26 UTC ( #959531=note: print w/ replies, xml ) Need Help??


in reply to Re^6: can't import using exporter
in thread 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

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
Re^8: can't import using exporter
by perl-diddler (Hermit) on Mar 15, 2012 at 08:29 UTC
    The entire program was included for anyone who wanted to reproduce the problem. If no one could reproduce the problem, it is because they didn't try. Not because the source wasn't there.

    Every workaround and suggestion to fix the problem didn't work. I'd say it wasn't a trivial problem.

    In fact chromatic, a veteran perler admitted, that it'd be too ugly to do it the way you did it.

    But thanks for proving the concept. It will useful on more than one level -- including on a reason why

    'use module' should simply do it's import mechanics on packages already defined in the current file.

    But believe me, I appreciate the example.

      I tried to hint at you that you should put in more effort into making it easy for other people to reproduce your problem. The easier it is for people to reproduce your problem and to inspect your code, the more likely it is that a solution or a workaround will be presented.

      Dumping the whole code, littered with stuff inconsequential to the problem, like Readonly and weird aliasing, is not what I call effort, and it also does not help in making the problem obvious. This is menial work that you should have done yourself instead of running around in circles and screaming that you are the only person in the world who has encountered this bug in 5.14.x. Whenever you feel that you are the only person to have found a fundamental bug in a language, or in a compiler, I recommend doubting your own understanding of the matter instead of running around and claiming you have found the bug and everybody ignores you. Also see I am great at communicating, but people are bad at listening. If you feel that nobody understands you, it is far more likely that your communication is bad, than that people are bad at listening.

      That you think that "use module" should do what you want is your prerogative. If you want to use Perl instead of your fantasy language though, it behooves you to read use to actually see what the use keyword does. Understanding that, and learning about how Perl exporting and symbol aliasing works will then also help you understand why your attempt fails as it does and why the BEGIN shehanigans are neccesary if you want to keep the rest of your program structure as is.

      Personally, I recommend splitting up the program into separate files and not relying on weird initialization dances like first initializing lexical variables, just to initialize global variables from them. Again, see App::fatpacker if you are hell-bent on producing a single file after developing your program.

        Um... there are a few things your example doesn't do nor solve, yet proves. (!?!?)

        you put 90% of the the program in BEGIN{}.

        You can't develop a program entirely in Begin.

        As soon as you start including parts not in begin, you'll run into the fact that you didn't duplicate all of the definitions -- the 2nd being outside of the begin, so that warnings/strict don't complain.

        Now you have 2 sets of defines -- those inside the begins, and those outside. You've doubled the development and maintenance.

        None of the standard ways to ways suggested worked. While you may have found a workaround that works for you, that is not proving there is not a flaw in perl 5.14.x -- and that standard methods others suggest don't work, neither about 2 dozen more than I tried before coming here.

        That's still fits the definition of broken usability, which still fits the definition of a bug.

        The problem with simplifying all those pesky aliases and RO var, is that oft' times the problem becomes induplicable.

        BTW, I have NEVER accused people of being bad at listening, I *SUCK* at communicating, ok? I know it. I'm stuck with it. I've taken courses, been to therapy, I'm defective -- unfortunately for me and the world. More times than not, I have it together enough to be understood without an interpreter, but have, on occasion, found that helpful!...

        I trebly hesitate to post anything for me running up into another wall or another hard place. It isn't usually worth the effort. I figured this time, I'd tried everything except rewriting the program all inside a BEGIN statement. The use Module(util). and it's usage was the last suggestion mentioned to me on 5.10, when this was brought up -- and worked then -- it doesn't anymore.

        The module suggested doesn't run on 5.14 without errors -- indicating that 5.14 has now broken it as well. Sure, it may be the modules fault, but if perl is breaking all these programs -- that is another bug -- it's not supposed to be breaking backwards compatibility without a "use feature"...

        Your program is a onerous, though proven, workaround, but it also gives ample fodder to any perl-hater out there about how broken a language perl is, because having to do that to have multiple classes in the same file is broken.

        But I honest still appreciate the work and effort you put into it, and have saved it... but that type of effort shouldn't be required for so little gain, nor should being required to write your code all one way.

        Perl was supposed to be about the freedom to do things 20-100 different ways, and now, it's all one way, or a straight-jacket (people go crazy that way, don'thcha know?)...

Fixed a year later...
by perl-diddler (Hermit) 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";

    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?

      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";

      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
        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...

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2014-10-21 04:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (96 votes), past polls