Re: How to declare globally visible subroutine like built-in ones ? Is it possible?

Are you sure you don't wan't use y; or require y; in z.pm?? This means that your depending on y.pm being loaded somewhere else, which is a pretty big trap for someone, yourself probably, debugging latter.

In any case, if you only want to use it from within package z, you could do this in y.pm

sub z::global_sub {
    print "global_sub working!";
}
[download]

If you don't like "G::global_sub", how about "::global_sub"? Think of '::' as a sigil (or twigil) for global. And as long as you use package declartions everywhere, you won't stomp on anyone elses namespace.

Comment on Re: How to declare globally visible subroutine like built-in ones ? Is it possible? Select or Download Code

Replies are listed 'Best First'.
Re^2: How to declare globally visible subroutine like built-in ones ? Is it possible? by bdimych (Monk) on Nov 06, 2007 at 12:14 UTC
>Are you sure you don't wan't use y; or require y; in z.pm?? Yes, I've given simplified example. Actually y.pm is a runtime library with many submodules: script.pl - "use y"; y.pm - load many submodules with "subnamespaces", and export many subs to the script.pl z.pm - one of submodules Perl is Perl, it allows almost all, I suppose it is possible to make my problem in some way...	[reply]
Re^3: How to declare globally visible subroutine like built-in ones ? Is it possible? by Anonymous Monk on Nov 06, 2007 at 13:00 UTC
If you're looking to avoid the overhead of loading all the submodules in y.pm but still having access to the code of y.pm proper, you could consider refactoring so that the big load/export is visible as y, but the actual code of y.pm occurs in y/actual.pm Then in y.pm `require y::actual; push @ISA, 'y::actual';` [download] This would leave y.pm with the same public interface, but give you the option of a leaner y::actual or y::tiny or y::whatever available. This will only work of course, if the code in y.pm doesn't itself depend on those submodules. You could also look at autoloading and/or custom import subroutines If you're just woried about namespace polution, s/use/require/	[reply] [d/l]