The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Edit: a disclaimer first. I think there is some theorical interest in the question, but it's actual realization is not risk-free (either because it somehow bypasses strictures, or because of performance, if not both). That's the main reason why I don't provide a full working example (also because I'm lazy, and my laziness is very happy with that first excuse :P). It's complicated. Basically, it's because perl lets you scope those variables dynamically but nor lexically. Or, in simpler English, you can tell how long you want a name to exist, but not where. For example if DWIM() made all the local function available in my::, and unDWIM the reverse you would have: planet() from NotMe would not be able to access $var, but would be able to call my::world(). And, if there already was a world() function inside NotMe, calling my::world inside NotMe::planet() would call MySelf::world() instead of NotMe::world() as expected... I see two (and a half) workarounds for this issue: 1) You can have a copy of each function in the current package with a name pattern that does what you want. Eg, add my__ before every local function. For example you'd declare: sub world { 'World' }; and call it as my__world from inside your package. Technically that second name would still be available to outside modules as MySelf::my__world, but you could just decide to never call my__ functions with a package prefix (or die by checking if caller is different from the current package). The my__ functions could either be created from the list of @EXPORTs, or by using AUTOLOAD to create the alias *{"my__$function"} = \&$function when you need it. 2) Also using AUTOLOAD, you can have a package My; so that when you call My::anyFunction from a package, it would look inside the calling package for "anyFunction" and call it if it exists. Although the two AUTOLOADsolutions look more convenient, they would be tricked by imported functions. So if you import Data::Dumper into MySelf, my__Dumper or My::Dumper would both call Data::Dumper::Dumper as if it had been defined inside MySelf. So I suppose the better solution would be to create an alias for every function that you export? There also the alternative of doing it the other way around: never importing function in the current package, for example: The issue with that one is that you would be able to call Ext::csv from any other package, even if it doesn't have the matching use in its file. In reply to Re: Making it clearer to say that a sub is defined within current package
by Eily
|
|