|Do you know where your variables are?|
Real world example?
Here's the source code for a module that pretty much only usees external modules, and each subroutine generates an object of the external module classes, then returns that object.
There are no exports in this case, because the majority of the code is Object Oriented, meaning that the functions don't need to be imported; the subs are methods of the object that was returned.
The RPi::DAC::MCP4922 module itself relies on modules of its own, namely it uses a core external API library. Notice that this use statement does import explicitly, in this case *all* of the functions that are exported by that API module. The API module then requires/uses other external modules, but only Exporter to be able to export the functions , and XSLoader to load the C/XS code that it requires.
So you instantiate a new top-level RPi::WiringPi object, then call its dac() method. It then makes a call to RPi::DAC::MCP4922's new() method which returns an object of its own class. Then once the object is returned to the top-level object, it in turn returns it to you.
In this case its a convenience thing. We include the necessary external classes and hide away the need for you, the caller script from having to use the module directly, and manually writing the DACs instantiation code within the script.