|We don't bite newbies here... much|
Yes, this error message sucks. It should list the two possible explanations with the most likely ("no such method") stressed more than the other ("*.al file missing because module not properly installed").
Note that this error message is a result of over-use of inheritance. In particular, this line from DBI.pm:
means that DBI "is a" Export and "is a" DynaLoader. Which means that if either Exporter or DynaLoad "is a" SomethingElse, then DBI also "is a" SomethingElse.
So some implementation detail of Exporter or DynaLoader becomes the baggage of DBI because it declares itself to be a descendant of them. In this case, the detail is that one (or both) of them "is a" AutoLoader (or similar). So DBI suddenly acts like an AutoLoader even though it had no desire to do so.
It would be better if Exporter and DynaLoader didn't use inheritance to get the AutoLoader functionality. And it would be better if DBI didn't use inheritance to get Exporter nor DynaLoader functionality.
Note that this realization has lead to Exporter now supporting better ways for it to be used, such as:
And note that some module authors have realized this problem with DynaLoader and worked around it similarly:
It is rather sad that the OO mindset so often jumps to inheritance as the answer for nearly every problem. Here we have two important core modules that mostly just need to provide one subroutine to the modules that use them, yet they encourage inheritance to be used to accomplish this.
It would be nice if DBI would fix this. Since DBI tries to be quite portable, it probably can't assume a modern version of Exporter, so it should instead use something like this:
Thus DBI would no longer produce this particularly misleading error message.
In reply to Re^2: What is the /auto/ directory used for? (inheritance--)