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

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 );

instead of

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

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.

Replies are listed 'Best First'.
Re^5: Export and use different package in module
by haukex (Archbishop) on Feb 22, 2019 at 21:11 UTC

    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/;

    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;

    For more than one function:

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

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

      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.

        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.