in reply to Re^2: Export and use different package in module
in thread Export and use different package in module

First, note that Library2.pm is missing the use Exporter qw(import);, so nothing is actually exported when you do use Library2;.

I suspect you added the package Library2; to Library.pm to work around that? However, the effect of doing so is that our %hash is declared in the current package, which is now Library2, so you're assigning a value to %Library2::hash, while what Library.pm is exporting is %Library::hash. Although you could change our %hash = ... into %Library::hash = ..., that's just fixing a workaround with a workaround, and the IMO much cleaner solution is to add the use Exporter qw(import); statement I mentioned above to Library2.pm, and just remove the package Library2; from Library.pm, which is then no longer needed, because now sub return_string will be exported from Library2 into Library and be callable there.

BTW, this:

use File::Basename qw(dirname);
use Cwd qw(abs_path);
use lib dirname(dirname abs_path $0);

[download]

Can be replaced by the more reliable:

use FindBin;
use lib $FindBin::Bin;

[download]

Replies are listed 'Best First'.
Re^4: Export and use different package in module
by chenhonkhonk (Acolyte) on Feb 22, 2019 at 20:54 UTC

    Library2 is outside of my control (not inherently), but I shouldn't have to modify the library if I'm not expecting to export stuff from IT, only make writing functions using the namespace easier. The library is actually Device::BCM2835, and since using functions in it also should be using values from it, I get things like

    #inside a function
Device::BCM2835::gpio_fsel ( Device::BCM2835::RPI_V2_GPIO_P1_12, Devic
+e::BCM2835::BCM2835_GPIO_FSEL_ALT5 );

    [download]

    instead of

    package Device::BCM2835;
#some place later in a function
gpio_fsel(RPI_V2_GPIO_P1_12, BCM2835_GPIO_FSEL_ALT5);

    [download]

    I found the our definition and then modification works with the hash, but it doesn't work with a sub even though I declare the sub the same way! If I try our sub, it's experimental.

[reply]
[d/l]
[select]

      Device::BCM2835 does export RPI_V2_GPIO_P1_12 and BCM2835_GPIO_FSEL_ALT5, so you should be able to say

      use Device::BCM2835 qw/RPI_V2_GPIO_P1_12 BCM2835_GPIO_FSEL_ALT5/;

      [download]

      to get those into your namespace. As for gpio_fsel, which apparently isn't exported for some reason, you could use this workaround:

      *gpio_fsel = \&Device::BCM2835::gpio_fsel;

      [download]

      For more than one function:

      for my $s (qw/ gpio_fsel gpio_set /) {
    no strict 'refs';
    *$s = \&{"Device::BCM2835::$s"};
}

      [download]

      To understand what's going on in the above, I recommend perlmod.

[reply]
[d/l]
[select]

        There's many things in the module, and I don't know which ones I'll want to use (I already use many). https://metacpan.org/pod/Device::BCM2835 It's really backwards having to turn off warnings to just add something to the current namespace without having to turn off warnings and hack around it, considering that variables are exported in a sensible way, but the functions aren't, and warnings/strict are useless. Can I change a sub declaration to force it to assign the sub to the same sub in the current namespace like the hash?

        Using the experimental 'lexical_subs' works for what I expect.

[reply]

In Section Seekers of Perl Wisdom