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

Re^6: can't import using exporter

by perl-diddler (Friar)
on Mar 14, 2012 at 06:57 UTC ( #959526=note: print w/ replies, xml ) Need Help??


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

I don't want to put define class point{ my x; my y; }

in a separate file.

I have 5-10 line modules that if I put in a separate file will multiple my work by 100%...

You don't split things to a separate file till at least 1000 in many cases, and I've seen manageable files in the 2-3k range, though 5k gets a bit unwieldy....

I have programs with 10 modules in 300 lines, and I should break them into 30 line modules each just because perl is broken?

So far every method that everyone "knows" works, doesn't in 5.14, and that one guy wants to claim 5.14 isn't broken (worse than 5.12 and 5.12 -- which were also broken in various ways)...

It's not like I haven't reported multiple bugs/RFE's...Usually met with resistance about not wanting to change the established order for fear of breaking existing code -- but I've got code broken by every perl upgrade since 5.6. Before that -- virtually nada (at least in the 5.x series).

I've been told on the perl-porters list that they way I am doing things should work just fine with import and such...

yet no one here seems to be able to make it work either.

Hopefully grandfather who's on that list will take note.

If I have to break it into separate files, then the language is broken.

packages are meant to be modular. They aren't. I complained and was told all I needed to do was use import.

I keep running into new problems in each new vversion.

(I have had some programs that worked in 5.12, but fail now in 5.14)...

So I wanted to make sure I wasn't missing *some* solution, that would work - before I go and file another bug about .. well... not sure!...

modules don't work?

I wanted 'use module' not try to include a module if it was in the same file... I got thoroughly roasted for that idea... yet it is so simple, but my guess is they can't make it work.

If it worked that way, then a package could be removed anytime, and it would work in a libdir the same as in program.

But now...it doesn't even work at all.

Sorry. Breaking apart a 800 line perl prog that was a 185 line shell script , into a 10-15 file perl monster is messed up.

These are not standalone packages -- they are mutually dependent classes. You don't put such things with dependent functionality in multiple files or your development becomes a nightmare finding what file you are supposed to be in.


Comment on Re^6: can't import using exporter
Re^7: can't import using exporter
by Corion (Pope) on Mar 14, 2012 at 08:26 UTC

    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.

      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.

      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
Re^7: can't import using exporter
by chromatic (Archbishop) on Mar 14, 2012 at 15:35 UTC
    I have programs with 10 modules in 300 lines, and I should break them into 30 line modules each just because perl is broken?

    Perl is working exactly as documented. There's at least one question a week here about how this all works, and every time the answer is the same.

    I wanted 'use module' not try to include a module if it was in the same file...

    How is that to work? Is the compiler to guess that subsequent code in the file will declare a package? Is the compiler to process the entire file once, looking for package statements, and only then start compiling the code?

    You don't put such things with dependent functionality in multiple files or your development becomes a nightmare finding what file you are supposed to be in.

    Sure I do, and I don't have these nightmare debugging problems you do.

Re^7: can't import using exporter
by afoken (Parson) on Mar 14, 2012 at 20:17 UTC

    Just a raw guess: Your "version control system" is called copy or cp and it does not scale to more than one file per project. Do you still live in the 1960s? Learn about git and subversion, both will solve that problem, and both scale to more source files than you ever need to use. Welcome to the 21st century!

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      ???

      Can you explain how you arrived at such a nonsensical conclusion?

      I've tried splitting a project early on into modules,

      it was a constant bother trying to find where a routine was -- in this window or that window -- is a window with that file even open? 'edit' -- oops -- file is being doubly diddled -- half the time on my other machine ---- so it's not listed with the same group as the other files... but those are minor oopses..

      The time wasted finding functions that need to be updated or interfaces that need to be updated/changed over multiple files because they are just being fleshed out and not really really to be split -- or really weren't designed to exist independently, but were, because perl can't easily have multiple classes in 1 file (as is demonstrated in the **beginner** books on perl OOP (Intermediate Perl).).

      The introduction to classes by the experts doesn't demonstrate using "use" to use other Class objects. It shows them all in one file. That's the starting point that almost nothing follows afterwards.

      Yet that's the first book (or it's predecessor by a different title), on perl classes and packages that someone would be likely to read. Yet nothing in perl works that way.

      You don't see a problem with that?

      Why doesn't anyone program the way Schwartz & bdfoy, and t.phoenix demonstrated? Do Schartz and bdFoy know nothing about perl.

      Why would the perl community support a perl that burns anyone who programs they way Schwartz and bdFoy taught? That's not to say they use that paradigm for everything, but for Dog says bark, and Cow says moo, separating things into 5 separate files would turn off anyone.

        perl can't easily have multiple classes in 1 file

        Sure it can. I do it frequently.

        I don't export stuff from classes, and I don't export stuff from packages in the same file. That way lies madness.

        Why would the perl community support a perl that burns anyone who programs they way Schwartz and bdFoy taught?

        Your conclusion does not follow from your premises.

        Why would the perl community support a perl that burns anyone who programs they way Schwartz and bdFoy taught?

        Can you post the code what you originally posted in can't import using exporter please?

        Maybe brian_d_foy and merlyn can tells us if that is what they teach (i wouldn't know what they teach).

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-04-24 00:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (557 votes), past polls