Re^4: "use" modules inside modules

$ntCapabitilies needs to be declared using our if you want to share its data between modules. The function is working presumably because it was defined in the same namespace as $ntCapabilities and hence can see its data. The accessor method is in a different namespace (Octopus?) and so can't see its data, even if you import the name. into the other namespace. This is because the imported variable is a package ("our") variable rather than a lexically scoped ("my") variable. All your values were assigned to the "my" variable, not the "our" variable.

Two other points:

One really should use warnings, not just strict. If you don't like all the warnings that use warnings; spews out, then clean up the code that is causing them. Getting rid of it to quiet the warnings is only going to cause you a world of trouble. If you have a very specific reason to do something normally warned about (e.g. you need to munge the symbol table), then turn off a specific warning for a specific block. Turning of warnings globally is a bad idea. Someone is paying you a lot of money to develop this code. It is important to give yourself every chance possible to catch mistakes.

You and your team could have done a much better job of reducing this code to the essentials than you did. For example,

you could remove all data from $ntCapabilities except one or two elements needed to show the problem.
you could remove all "use" and "require" statements except the ones causing the problem. We don't have your family of modules and can't reliably run your code to see how it works on our system if you leave those extra "use" and "require" statements in.

Best, beth

Comment on Re^4: "use" modules inside modules Select or Download Code

Replies are listed 'Best First'.
Re^5: "use" modules inside modules by Bloodnok (Vicar) on Jun 28, 2009 at 20:17 UTC
I've worked in environments (including the current one) whereby, entirely due to legacy reasons, cleaning up the code from a warning(s) POV, is not feasible with in the constraints of the project at hand - indeed, it would require a self-contained project to totally clean up the code. The end result being that, wheresoever legacy code had/has to be used (pun intended) from within well-behaved code, it was/is done within a local block in order to circumvent the multifarious warnings that would otherwise be generated i.e. `{ no warnings; use Legacy::Module; }` [download] The removal of the warnings from the legacy code can then be done in piece-meal fashion as a background task without compromising the aggressive timescales for the new code. A user level that continues to overstate my experience :-))	[reply] [d/l]
Re^6: "use" modules inside modules by bogaertb (Novice) on Jun 29, 2009 at 14:15 UTC
In this case it was not an issue. All perl scripts were run using -w. Changing that to include `use warnings 'all'` rather the using `#!/usr/bin/perl -w` did not result in more warnings neither at compile time nor at run-time (for me warnings are an indication of a possible coding error).	[reply] [d/l] [select]
Re^5: "use" modules inside modules by Anonymous Monk on Jun 29, 2009 at 06:16 UTC
Hi, Thanks, but all scrips contain the shebang `#!/usr/bin/perl -w` [download] Isn't that the same as use warnings?	[reply] [d/l]
Re^6: "use" modules inside modules by Anonymous Monk on Jun 29, 2009 at 06:36 UTC
No it isn't, see perllexwarn	[reply]
Re^7: "use" modules inside modules by bogaertb (Novice) on Jun 29, 2009 at 07:32 UTC
Thanks for the pointer but as far as I can see removing the `-w` commandline option and introducing `use warnings 'all';` should not result in more warnings as I understand the command line option is more 'crude' where the use warnings allows for more fine-tuning? Or am I wrong here? Anyway, at least when compiling the code I do not get more warnings then before (basically none as I do not want any warning to show up when the programs run - and basically till now I was able to keep it like this). I will check it again on runtime after introducing these changes.	[reply] [d/l] [select]