The code block following that comment:

 sub main_package_vars {
        foreach my $name (@_) {
            no strict 'refs'; *{ $name } = sub {
                my $p = shift;
                $p->{$name} = $_[0] if @_;
                $p->{$name};
            };
        }
    }
[download]

This creates accessor-style subroutines with names given in @_. You can call it as

main_package_vars( 'Some::Namespace::foo', 'main::bar', 'baz' );
[download]

Yuck! Don't you think the 2nd version we all came up with (somewhere below near the end of this 'Q') is much better -- it just allows it to be called:

package_vars( qw( foo bar baz) );
[download]

in each package, no references to what package it's in. Actually, made two, 'instance_vars' and 'class_vars', for defining/accessing either '$p->{name}' or 'our $name' type-vars in a package. That way each package can clearly declare their vars appropriately at the top of each package.

Maybe not that important in all projects, but this one has 11 packages in 1 file, and should shorten it up considerably and make it more readable -- along with the other 'macros' I can now add, now that I understand how the concept works! Major Bonus!

In general, it's not my first choice, to pull in in non-Core CPAN packages when I don't have to. Makes my package more prone to outside failure and slows down my development over using my own well-known routines (which usually are very simple for what they do). Exceptions are when something saves me tons of work for the trade-off (which I usually don't mind -- it's a favorable investment/trade-off in time), OR things I don't quite understand as they seem too much like magic.

Those I accept when time or interest doesn't let me go off and figure out how to do them myself (and there are alot more than I'd like in this category), BUT, I insert them in my queue to eventually find out enough to do my own in those cases, since for what I want, like in this case, 10 lines of code I understand can me including hundreds lines of foreign, non-Core code that I don't. I'd think most perl programmers are like that, or they wouldn't be perl programmers -- they'd probably be using java or some other application language... eh?