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{'Parse_Options.pm'}=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.
|