Sorry to be a naysayer, but I would not put these on CPAN.

It's no problem at all. I am certainly not all gung-ho about putting these on CPAN. I just wanted to see if they'd make anyone else's life easier as they have for me.

Package::Require sounds like it is doing something that Perl already does for you. See the documentation for require, and look at %INC.

Not quite. First of all, I come across the 

eval { require $somepm; };
quite often and the eval will be executed regardless of whether a module has already been required. This is slow.

Also, how often do you see the 

$somepackage =~ s{::}{/}/g;
come up? This module contains simple methods for going from a file to a package and vice versa and uses Memoize for speed.

Lastly, %INC doesn't record modules that it has already FAILED to require, but this module will handle that for you.

Package::Exporter does something you shouldn't want to do. Exporting functions without telling the user what you are exporting increases the odds of encountering software conflicts. Therefore a well-designed module should export as little as possible. (Exporter deliberately warns about this point for a reason.)

I tend to disagree because as a user of Package::Exporter, I'm at least somewhat aware that if I do 

use Package qw/SomeModule/;
then I'll be able to access all the subs in Package::SomeModule as just SomeModule.

The interface of all three of these modules is so minimal that there almost ISN'T an interface.

Your code example is not long enough to clarify what Package::Overridable does or how it is supposed to work. I tried to download it from your site so I could see for myself, but the connection timed out. However your reference in your comments to TestPackageOverridable and MyTestPackageOverridable suggests that the API is not one I'd like.

Package::Overridable basically provides an import sub to its children. So when a child class is imported, it will look in $PERL5LIB for a package of the same name but beginning with My. This makes it possible to transparently override code in development that will not be deployed to production because it's not under source control. I find this EXTREMELY handy.

In reply to Re^2: RFC: Some of my toolkit modules by bennymack
in thread RFC: Some of my toolkit modules by bennymack

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.