Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re: Correct syntax for using $INC to keep modules in same file

by Anonymous Monk
on Jun 26, 2012 at 05:16 UTC ( #978335=note: print w/replies, xml ) Need Help??

in reply to Correct syntax for using $INC to keep modules in same file
in thread can't import using exporter


Correcting tobyink seems redundant after corion/chromatic showed you, and after tobyink corrected himself

Heck, it even seems trollish

  • Comment on Re: Correct syntax for using $INC to keep modules in same file

Replies are listed 'Best First'.
Re^2: Correct syntax for using $INC to keep modules in same file
by perl-diddler (Chaplain) on Jun 28, 2012 at 00:27 UTC
    Corion and chromatic showed me what?

    You are partly right about tobyink -- but even with the spelling corrected the module he suggested didn't compile on 5.14 on my system. Chromatic's showed me that he could tell me to split my 1 program into 20-30 separate files -- which would be pretty clear -- wasn't something I was about to do -- I want to use small classes, some maybe 5-7 lines long to define typed data, I don't want to separate each class definition out into a a separate file. It wouldn't work for me.

    Only when a module is *stable* -- and not being developed any more, and is called for in multiple programs, is it time, IMO, to split it out into it's own module.

    Otherwise it adds unnecessary complexity.. Corion went on about spelling errors long after they were corrected and still didn't work. His example using BEGIN throws away much compile time checking and introduces duplicate declarations that *DO* get out of sync when they are done -- (I've seen others complain about it on the perl todo list, and I've had the experience myself).

    So an anonymous twit intimating posting offtopic aspersions seems alot closer fit to a troll than anything I wrote. Nerdbutt! ;-)

      I don't want to separate each class definition out into a a separate file.

      If you were truly using classes, you wouldn't have this problem. You're not using classes. You're reinventing modules, and that badly.

      Otherwise it adds unnecessary complexity.
      use mem &{sub(){$::INC{''}=1}};

      That's necessary complexity? Reimplementing something Perl already knows how to do for you—in an ugly and incomplete fashion—is both necessary and sufficiently simple?

      Even the syntax use mem 'Dbg'; would be far less blepharitic—no less obnoxious, but at least it would keep the ugliness to only one spot in your code.

        But it wouldn't accomplish the same purpose. Besides, I only accept responsibility for the 'use mem' pragma.

        The only purpose of specific line of code is to get around perl's inability to know when module Dbg has already been defined and, therefore, doesn't need to be searched for.

        I'm using classes -- things without separate files, not modules -- which, being modular, do live in separate files. (Are we picking nits about definitions?, you say half-dozen, I say six, or such?)

        So how does one tell Perl, in code that looks like perl code, and not some sort of assembler, that a 'use statement' should not go searching for files, but should use the 'in-memory' version instead? Note: BEGIN{} sticks out like a sore thumb. It doesn't fit with any other pragma.. so it doesn't qualify.

        But I'm sure you love code like this:

        { package Parse_Options; # {{{1 use warnings; use 5.14.0; use mro; our (@ISA,@fields); use mem &{sub(){$::INC{''}=1}}; use mem &{sub(){our @fields = qw(quiet verbose numprocs ratio_jobs + srcX dstX); our @ISA = (qw(Data::Vars FileList + main)); }}; use Data::Vars \@fields,{quiet=>0,verbose=>0,ratio_jobs=>6/5};
        In order for 'Data::Vars' to work correctly and in order for class inheritance to work at compile time, you have to have your fields (to Data::Vars, and Exporter -- similar problems) declared at 'BEGIN' time -- that's what mem does --- it forces the evaluation of it's args at BEGIN time.

        For example, the use Data::Vars above has initialization args for the default values -- If I misspell or change any -- they are caught at compile time.

        If you want the things you are importing with Exporter to by type-checked at compile time, you have to have them included at BEGIN time by using BEGIN or something like the above.

        I don't remember it always being that way -- it seemed to be something that popped up in 5.12 or 5.14 -- and that was one of the major breakages I saw.

        Another was putting use warnings/use strict; after every package statement --- not just once at the top of the file. I don't remember that being required before 5.14 or maybe 5.12 (my perl pretty much jumped from 5.10->5.14...)....I spent little time with 5.12...

        You think stuff like the above drives you crazy??? I've just given up on perl making sense and decided to code around everything that doesn't make sense -- it was too much work trying to figure out the 'why's ... I could spend all my time doing that or getting something done.

        As it stands, my Wave2Flac converter coverts 600MB Wave->300MB Flac with all optimizations in 8-10 seconds (of course it runs multiple jobs in parallel and uses a queue). Of course it's not really 'done' (want to add both Wav2mp3 & Flac2mp3...)... but that may be a while...dunno.

        Previous working version was ~ 3-4 years ago, and then it took about 30-45 seconds/album.

        My duplicate / outdated rpm code can sort through 13k rpms -- reading each via rpm, in a 2-phase parallel merge/sort -- <2 seconds. I'm not sure why the shell script version took multiple minutes...but it didn't run with 9-10 threads either.

        Reading through old stuff...(I sometimes do)...

        I do not understand what you are trying to say.

        use mem, which for simple assignments, I've found can be more easily simplified to:

        use mem ($::INC{''}=1);
        is a substitute for the UGLY BEGIN block. If there is a more structured way to do it that is prettier, please tell me, but I find BEGIN blocks to be ugly -- I don't like all caps keywords -- they are hard to type and bother my RSI when I do it. So I tend to find lower cost workarounds.

        But the bit you said about "use mem 'Dbg'" -- I don't understand -- are you thinking or saying that such would be a substitute for the previously mentioned code or that I should write a separate module to make it so? If it is the latter, yeah, I could, but its a tradeoff. Any module that doesn't have mem in it's library path can recreated it in 1 line:

        After that, I can use mem and anything on it's parameter line will be evaluated at BEGIN time without all those ugly BEGIN blocks.

        The most common usage I have for use mem (besides assigning to INC so a module in the same file doesn't have to be loaded), is to assign to ISA and EXPORT at BEGIN time, so various modules, including Exporter will work correctly.

        Exporter won't work fully if you don't do that. It will include the functions you want -- but not their types. I try to always use typed functions. You only get the benefit of that typing if you have your EXPORT list included at BEGIN time.... usemem does that.

        So I'm not sure what you are suggesting I write a module that would have to be included to provide syntactic sugar so it looks nicer? (not necessarily a bad thing, but right now utility beats pretty... pretty comes after it's working -- and I do go back and pretty up code...but usually on a 2nd revision...1st revision is to get it working)...

        Is that wrong, or what are you suggesting?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://978335]
and the monks are mute...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2018-06-24 12:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.