in reply to Re: One module to use them all (proxy moudle that exports subs of other modules)
in thread One module to use them all (proxy moudle that exports subs of other modules)

The OP has existing modules which do not have an import function because they do not have use EXPORTER;. Would it not be easier to add that line than a custom import function? Adding *twoFunction =\&Mod11146642::All::twoFunction; to the new module Mod11146642::All should do the same thing for this application and not affect anything else.

Long UPDATE to Clarify my point

Nataraj has posted the following update to One module to use them all (proxy moudle that exports subs of other modules).
Update: Partially solved here. This solution (Re: One module to use them all (proxy moudle that exports subs of other modules)) works for modules that uses Export for exporting. For other modules I added desired subs to export list explicitly. This did most of the trick.
From this I assume that most functions ‘work’ (i.e. The application tldr.pl can access them with unqualified names) . Later, he tells us that all the exceptions are in third party (‘not really mine’) modules which do not have use EXPORTER. It is reasonable to assume that these modules do not have an appropriate ‘import’ function. At least three solutions have been proposed. Any one of them would ‘work’ . None of them are exactly what the OP was hoping for.

The second and third option are probably not available for third party modules. The first option has the advantage that all extra code is added to the ‘proxy’ module ‘ModAll’. This method fails to meet the OP's expectations only because the proxy module must be manually updated every time the library of third party functions is reorganized.

Demo of ‘manual’ method

Modification of Re: One module to use them all (proxy moudle that exports subs of other modules)

The following files are unchanged

EXPORTER has been removed from Mod3.pm to simulate a 'third party' module.

package Mod3; use warnings; use strict; #use Exporter 'import'; #our @EXPORT = qw( m3 ); sub m3 { 'm3' } __PACKAGE__

Manual ‘import’ added to ModAll.pm

package ModAll; use warnings; use strict; use Mod1; use Mod2; use Mod3; use Exporter 'import'; # Supply function name ‘m3’ manually (not in any EXPORT list) #our @EXPORT = (@Mod1::EXPORT, @Mod2::EXPORT, @Mod3::EXPORT); our @EXPORT = (@Mod1::EXPORT, @Mod2::EXPORT, ‘m3’); *m3 = \&Mod3::m3 # hand code result of missing import; __PACKAGE__
Bill

Replies are listed 'Best First'.
Re^3: One module to use them all (proxy moudle that exports subs of other modules)
by pryrt (Abbot) on Sep 04, 2022 at 22:25 UTC
    Would it not be easier to add that line than a custom import function?

    That assumes that you know all the functions exported by all the sub-modules before designing the All.pm module. The OP specifically contradicted this assumption: "their export list is not fixed and changes from time to time".

    So, ::All needs to be designed in such a way that if ::Two v2.00 exports just twoFunction() , but ::Two v2.01 exports frobnicate() as well, ::All can still work without having to be updated.

Re^3: One module to use them all (proxy moudle that exports subs of other modules)
by LanX (Saint) on Sep 04, 2022 at 20:56 UTC
    > The OP has existing modules which do not have an import function because they do not have use EXPORTER;.

    Sorry, this doesn't make sense.

    You can have a sub import function without using the customized one provided from the module Exporter °

    And without import no way to export.

    Hence if the OP wanted to call those module-subs fully qualified anyway (because they are not exported) there wouldn't be any problem. He could just require the modules, and call the subs in their native package.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

    °) have a look at the provided Two.pm "using its own import()"