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

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.

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

    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]
      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

      Nowhere in this thread are warnings turned off, so I'm not sure what you mean. If you mean strict, then yes, turning off strict 'refs' is necessary when doing this kind of exporting/importing with strict enabled. More specifically, it's required because the second method I showed uses Symbolic references to build the names of the symbols from strings. Exporter does it internally too.

      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.

      The code I showed copies a reference to a sub from one symbol table to another, which is how importing/exporting works in Perl. As I said, have a look at perlmod, or perhaps my post here (the paragraph beginning with "Once you understand...", the first two bullet points, and the "Update").

      Other than that I'm not sure I understand your expectations, especially in reference to Lexical Subroutines. Maybe you could show with code what you are expecting to be able to do?

      considering that variables are exported in a sensible way, but the functions aren't,

      Yes, I think it's a limitation in Device::BCM2835 that it does not export its functions, and IMO one that might be worth a request to the module's author to see if they might add that. But as long as they don't, and you don't want to patch the module either (as you said), you'll have to work around it, for example with the code I showed.

      warnings/strict are useless

      Sorry, I don't understand this point. If you mean the no strict 'refs';, then its effect is limited to its lexical scope, which is why I put it inside the loop, so that it does not affect the rest of the program.

[reply]
[d/l]
[select]

        A hash is exported normally using our %hash = (); and adding to it works after doing package <something>;. Functions aren't, and I have to use experimental our sub to do it, which doesn't make sense (since both hashes and functions would expected to be managed in the namespace the same way). When it came to strict/warnings, they offered no information on resolving the issue, which as far as the language is currently concerned, only variables can be handled.

[reply]

In Section Seekers of Perl Wisdom