in reply to Re: "use" modules inside modules
in thread "use" modules inside modules
Show us some code!
Show us sufficient code to demonstrate the problem, but no more than that.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^3: "use" modules inside modules
by bogaertb (Novice) on Jun 28, 2009 at 16:39 UTC | |
Here we see the (among others): This is the Octopus.pm module (at least a the beginning): So here again we have the usage of the module Capability because this module contains functions that logically belong there (it is a module having capabilities of elements it is dealing with). Now we turn to the Capability module. Half of this module is data (intented to be static). The rest of the module are accessor functions to access the data elements to prevent "direct" usage of the hashes defined inside but rather retrieve the data through the accessor functions. We are not using the Exporter (I tried it but it made no difference). The problem I have is occuring on this hash. To determine the presence of an element I use the statement When I remove the call require Capability.pm from Octopus.pm and replace the function call by the code executed by the function the program is running fine, if the require statement is present and I use the accessor function, the program fails for exactly the same element that was OK when the require was removed. It is the intention that the data hash remains "local" to Capability.pm. I hope this is sufficient code allowing a "judgement". | [reply] [d/l] [select] |
by ikegami (Patriarch) on Jun 29, 2009 at 01:03 UTC | |
First, let's simplify your code a bit. In the .pl file, replace with
In the .pm files, remove the following
It makes no sense to tell perl where to find the library after it's already been found! Now on to your question.
From where? The .pl file? There is no such variable there. You would have to export %ntCapabilities in order to do that (and roll out your own import since no module will help you export a lexical variable). But since exporting variables (as oppose to functions) is rather fishy, it would be better to create an accessor (sub is_capable?) and export the accessor from Capability or use its full name.
| [reply] [d/l] [select] |
by Anonymous Monk on Jun 29, 2009 at 06:10 UTC | |
| [reply] [d/l] |
by ikegami (Patriarch) on Jun 29, 2009 at 14:14 UTC | |
by bogaertb (Novice) on Jul 03, 2009 at 06:15 UTC | |
| |
by ELISHEVA (Prior) on Jun 28, 2009 at 19:14 UTC | |
$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, Best, beth | [reply] [d/l] [select] |
by Bloodnok (Vicar) on Jun 28, 2009 at 20:17 UTC | |
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. 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] |
by bogaertb (Novice) on Jun 29, 2009 at 14:15 UTC | |
by Anonymous Monk on Jun 29, 2009 at 06:16 UTC | |
Isn't that the same as use warnings? | [reply] [d/l] |
by Anonymous Monk on Jun 29, 2009 at 06:36 UTC | |
by bogaertb (Novice) on Jun 29, 2009 at 07:32 UTC | |