I like the idea of only bringing in parts as needed. I have a script that converts A to B and B to A, and they are largely separate code. But the user sees one script with common arguments, and it loads only the code for the one it needs when invoked.

use will not work that way, because it is evaluated at compile time and the if at run time. However, you can do the same thing as use by calling require followed by import. For object-oriented modules, the import may not be needed anyway.

Now, as to the scope: If you don't call import at all and it works OK, then you have no issues. The module remains loaded so objets of that class continue to work, and you can refer to DBI::Pretty::File as a class name or scope name subsequently and it's still there. Subsequent require's are harmless, so you could make sure it's in at each point you name it directly.

If the module's import routine "does something", there are two things it can do: it can manipulate the current block scope like use warnings; does. It does this by modifying certain magic variables that are like local in that they pop back to their old value when the user's scope is done.

Normally, non-pragmatic modules "do things" in the import by modifying the symbol table of the caller. That is, add symbols to the caller's package. This will alter your namespace and is totally insensitive to block scope.

I hope that helps,
—John