Re^4: global var

[tultalk]

Hi:

Thank you for this informative reply. I had not read anywhere this explanation:

use xxx;    #imports all of the symbols in @EXPORT
use xxx (); #imports all of the symbols in @EXPORT
use xxx qw(OpenConnection $LoggedOn_user_id); # imports
 # all of the symbols in @EXPORT AND subroutine OpenConnection
 # AND the scalar $LoggedOn_user_id from @EXPORT_OK
[download]

I was originally used the first example and calling all the subs with manageusers::sub and I guess that is why they worked and the scalars were imported also.

I recently took a fellows advice and changed the export to our EXPORT_OK and am now having to put the called subs by name in use xxx qw(sub1 sub2... sub10) to get those calls working again.

I guess its back to the drawing board on this.

I did read that it is not good to use xxx; as it imports everything into that module, even subs/scalars that are only for other modules.

Anyway thanks for the information and with that clarification I can probably resolve my issues.

Best regards

[poj]

imports everything into that module, even subs/scalars

The advice in What_Not_to_Export regarding scalars is this

Do not export variable names. Just because Exporter lets you do that, it does not mean you should.
 @EXPORT_OK = qw($svar @avar %hvar); # DON'T!
Exporting variables is not a good idea. They can change under the hood, provoking horrible effects at-a-distance that are too hard to track and to fix. Trust me: they are not worth it. To provide the capability to set/get class-wide settings, it is best instead to provide accessors as subroutines or class methods instead.

Which is where I think this node started with the problem

$userid = $manageusers::LoggedOn_user_id;

and I think you were on the right path here in eliminating the global variables

I also changed $LoggedOn_user_id to a function call &GetLoggedOn_user_id to deliver the number to the other module and it still does not work.

I think you now know to make it work.

poj

[Marshall]

Please see my 3rd attempt at explaining this "use" business.

One problem with importing all of the @EXPORT stuff by default is that this can cause name conflicts. Also, if a program is large and uses a lot of modules, having an explicit import list can help with figuring out later what module something is in.

Yes, if a variable is an "our" variable, the fully qualified name will work even if that particular symbol is not exported/imported. subs/functions go into the package symbol table in any event. One aspect of this is that there is no such thing as a truly private function in Perl. It is considered very bad form to call some function that is not part of the public interface, but Perl will not stop you from shooting yourself in the foot like that. If you know the function's name, you can call it.

Oh, another point, in the @EXPORT list, you can ditch the leading & character (that's an old Perl 4 artifact). Put "someFunction" instead of "&someFunction".