While it may be more fashionable these days to use object orintated coding techniques there are still many situations where it makes more sense to use exported functions as an alternative interface to your code. That is to say, where it makes more sense to set up your module to place functions directly into your current namespace when you load the module with a "use" statement where they can be called directly

Though it is possible to 'copy' functions and varibles into another namespace by hand by playing with typeglobs, almost no-one does this, instead they use the Exporter module. This is a module that ships with perl that allows you to declare in a set of package wide arrays and hashes which functions and varibles should be exported and which extra funtions and varibles should also be avalible if the user passes extra info in the arguments to the use statment.

This works quite well - up until a point. The problem is that it suffers again from the problem that the overload pragma had; You're declaring all the export stuff somewhere where that's not right next to the code you're actually exporting. This means that you have to keep scrolling up and down your code to add in new functions, and it's very easy to forget to update the exporter list. Also, it means that you have to type the name of each function twice...and that's not a very lazy thing to do. When it comes down to it, it's a pain to maintain the code.

The solution of course is to have an attribute on each method that declares if it's exportable and in what situation. Which is what this module does. Now you can just say right there what you want to use, and it's a lot clearer when you're reading a method exactly when and how it will be called. Good stuff.