|Pathologically Eclectic Rubbish Lister|
Yes, polluting the UNIVERSAL namespace by adding a method that can impact every single other class used is so much better than writing one simple, well-understood line of Perl code.
So, when I run across a line of code like:
in some Perl code, I'll likely suspect what it might be doing. But, especially the first time, I likely won't be completely sure, especially not on all of the details. So I'm likely to want to go read the documentation for this routine. And it is so easy to imagine having no idea where to find that documentation. Especially if the loading of UNIVERSAL::require was done from some other code file (yay for action at a distance).
A much less cute interface for this functionality would have been a much better idea. Running into code like:
would make the breadcrumbs from the mystery code to the module that documents it obvious in the typical manner of Perl modules.
Such an interface would also prevent weird surprises when you misremember a similar method name on some other class and get silent behavior very much different from what you expected and then waste a ton of time trying to figure out what is going on. Because the silent behavior was made possible by the loading of some module by some code that has almost nothing to do with the code you are working on. Action at a distance at its finest.
In reply to Re^2: The 'eval "require $module; 1"' idiom (UNIVERSAL--)