Re: Private namespace package question

[count0]

in reply to Private namespace package question

From what you've shown, it seems Private.pm's only purpose is to load a group of commonly used modules. This was probably done by the original author(s) to avoid retyping all of those 'use ...' statements into each of the Perl scripts.

IMHO, this is usually a bad idea, and can be avoided through better design. If each of the scripts always needs each of these modules, they can most likely have much of their workload, and page displaying functionality done through a common module.

That said, you should also understand clearly what that warning is about. If a module included by Private.pm exports anything (for example, Carp.pm exports carp() and croak()), you will not be able to use it from outside of Private.pm. Instead you will need to fully qualify the name (Carp::carp() for example).

[apprentice]

Thanks, count0, your answer leads me to another question about the warning:

You say that the warning means that outside of Private.pm I would have to call Carp::carp() since Carp.pm exports carp() (apparently only to Private.pm, doesn't carry over to anything that loaded Private). But, if a module doesn't export anything, doesn't that mean I would have to call its subs in the same way (somemodule::somesub())?

If that last bit is true, is there any way to have one module load all the modules everything would need and then allow all other modules to use the subs of those modules without having to prepend the package names(as long as they were exported)?

Thanks again!

Apprentice

[Ovid]

apprentice wrote:

is there any way to have one module load all the modules everything would need and then allow all other modules to use the subs of those modules without having to prepend the package names(as long as they were exported)?

Um, yes, but you really don't want to do it. What it involves is writing a custom import routine in Private.pm and then using goto to call the other modules import routines (this prevents the call stack from being updated):

sub import
{
    # using goto to avoid updating caller
    # This will export everything to the package
    # that called this one
    goto &Foo::import;
}

Hmm... in retrospect, this also means the you can only export one package's subs from here. This is a tougher problem than I thought. On the other hand, whenever someone winds up trying to do stuff this tricky, it usually means that a redesign should be considered.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[tilly]

The task is not hard to do if you use caller to find what package you want things exported to and then use an eval to call all of the appropriate imports in order.

This will not, unfortunately, work for the pragmas though.