Thanks, Corion.

schwern, if you are reading this and are hopelessly committed to keeping your attitude problem, then jump to the "horizontal rule" below. :)

I didn't file a bug report on base.pm because I never had a problem with it. I also never had a clear picture of why it would (infamously) fail (I quite recently filed a bug report in RT based on a thread at PerlMonks just because I saw what the real problem was even though I'd never run into the problem -- I don't think I had ever even used the module).

So I did a quick search because I was curious why so many of us just knew that base.pm was no longer to be trusted. I didn't find it, but the second item I did find was me telling a poster complaining about a problem with base.pm that they needed to file a bug report with a module author (though, in this case, it was the author of Quantum::Superpositions, which was using base.pm in a way that was incompatible with older versions of base.pm and this was in 2000 so I'm not surprised that I said "tell the author" rather than "file it in RT").

So where do a I file a bug report for schwern ? This author shouldn't be so disconnected that he doesn't realize that for years it has become common knowledge that his module can't be trusted. (:

I've applied jdporter's patch implementing his excellent idea of supporting [rt://base] for easy linking to RT queues. That will help with encouraging things that should go to RT getting to RT.

I was so glad to see Re: 'base' versus @ISA, why? because it included...

Thank you all for your bug reports regarding base.pm which came out of this discussion.

...a reply suggesting that a bug report should be filed...

I particularly enjoyed the well written test cases

...a clear test case. No, it wasn't all neatly wrapped up in a pretty package with a nice bow, but it was quite clearly described and included the exact line of code that triggered the bug by its mere presence.

Although not necessary it makes identifying and debugging your problems a pleasure for the overworked author to fix your problem for free.

I "fixed my problem for free", already, you ungrateful bozo. I fixed it by no longer using the module that you broke with your repeated, sloppy addition of features without much apparent regard for, well, for avoiding breaking things. My heart just bleeds for how over-worked you are. I personally have so much free time that I'm often at a loss for what to do with it. I feel awful that I didn't take the time to research and wordsmith and primp and test so that I could provide for you upon a silver platter the complete solution to everything that is wrong with your module that I don't use.

Thank you for making use of the centralized bug tracker which many people labor to keep running and useful for free.

And thank you for thanking PerlMonks for providing you with this valuable information. Although those who keep it running are paid lavishly, your gratitude makes their leisure-filled days that much more blissful. I'm terribly embarrassed that it took nearly a week from the time that these details were published before the information reached you. We'll try to aleviate your ignorance much more quickly in the future.

which came with your patch

You can't fix reckless featuritis with a patch. Not all problems with modules can be turned into a patch. And not all problems with modules are appropriate to send to RT. One of my big problems with producing patches to things is figuring out what would be acceptable to those with the power to apply the patch. Usually a module author has some guiding design principles / vision that means that not all ways to fix it are equally acceptable (though that may not be the case with base.pm so perhaps just any old patch would just be blindly applied so long as it fixed the immediate problem here).

When I first or second heard of base.pm failing to require the requested module, I took a quick look at the base.pm source code. Part of my motivation for this was that it seemed nearly pointless to me to have a module whose purpose was to replace just push @ISA, qw( Foo ); with use base qw( Foo );. So the idea of sometimes not doing the require seemed like a dumb feature and I wanted to know what motivated it. And looking at the source code told me that what used to be a very simple, elegant module had become a very complex module that did a bunch of stuff with %FIELDS (?). Clearly, the purpose of base.pm had changed from "a nice shortcut that lets you avoid typing in the module name twice and thus tells you (because the require fails quite informatively) when you make a typo in the module name" to something much more complex that was way beyond that original scope.

And such a basic bug being released and not quickly corrected told me that there wasn't being effort put into even keeping good support for the original purpose so I knew that base.pm was no longer appropriate for its original purpose and I stopped using it for that purpose (which meant I stopped using it completely since I've never used %FIELDS).

No, I didn't file an RT bug report for "the purpose of base.pm has changed". I deeply regret that I didn't provide a patch to fix that. q-: The benefit of the original purpose was rather small so I figured (hoped) that there was more benefit in this new purpose and that some people had considered the situation and concluded that usurping the name "base" for this new purpose was worth the small loss.

Now that I've spent too much of my vast expanse of leisure time dealing with someone's attitude problem, I can move on to dealing with their poor sense of design.

If the intent is for base.pm to continue to serve its original purpose, then require failing must be reported. base.pm is a horrid idea if "use base qw( Foo::Bar );" silently ignores that I haven't installed the Foo::Bar module (which also means that it silently ignores that I meant to type "Food::Barf"). (update: This also means that it silently ignores that I've introduced a syntax error in Bar.pm (thanks again, Corion) or that I've set the permissions wrong on the Foo directory, etc. etc.)

I realize that its support for %FIELDS means that base.pm "needs" to be able to deal with being given a module name for which require would fail because the module code is actually in-lined in some other file. base.pm's two-faced way of dealing with this [ 1) don't bother to require if $VERSION exists, 2) don't complain if require fails ] is misguided. Do step (1) well so that step (2) isn't needed. Step (2) is completely unacceptable. To be clear, step (2) invalidates (IMO) the original purpose of base.pm ("a nice shortcut that lets you avoid typing in the module name twice and thus tells you (because the require fails quite informatively) when you make a typo in the module name").¹

¹ And adding a step [ 3) complain if the package is empty after the require ] doesn't improve that problem. If $VERSION exists then the package isn't empty so step (3) doesn't compensate for problems with step (1) in the least. Leaving step (3) in place would be handy for systems with case-ignoring file systems, however. It'd even be nice if Perl's own require issued a warning for such.

So step (1) needs to be improved. Clearly $VERSION needs to be defined, not merely exist. It is possible that even that may not be quite enough of a check. Someone needs to do some work / checking / monitoring to determine how well that works and to come up with better criteria. It appears clear that the module maintainer won't be doing that, however, so I hope someone else will volunteer (I still won't be using the module so my hand isn't up).

People who use base.pm but don't bother to define $VERSION in their in-lined module code will just have to define $VERSION (or stop using base.pm or do the work to come up with a better criterion for when require isn't needed). The base.pm documentation needs to be very clear on this. base.pm should probably augment the error message from require failing by also noting that $VERSION was not defined so people who run into this problem will immediately be directed toward how to fix it.

Perhaps if $VERSION isn't defined and then require fails, base.pm could search for any subroutines being defined in the requested package and, if there are some, produce a much more verbose message about how they now need to define $VERSION for the in-lined module to work with this fixed release of base.pm.

Anyway, I'm tired now and need to lay about for a few hours before phoning my accountant about my PerlMonks stock options.