After reading up on the links, and trying to re-architect, I did the following:
- Updated the code to use strict
- Updated the code to use warnings
- Re-ordered the use commands and @EXPORT declarations.
When I was reading through the camel book, it mentions that the package statement, the @EXPORT statement, and the use commands need to be at the beginning of the modules, but I didn't realize that my modules didn't have them in the same order.
I think when I started explicitly scoping the function calls and variables, it fixed the issues so Company.pm could use SnapMirrors.pm.
In short, I want to say "thank you" to everyone. It was a lot of work, but I think I have better code now. And it's good to know that I have somewhere to turn to when I'm at wit's end. :) | [reply] |
When I set it up that way, I was getting undefined subroutine errors from other modules that both Company.pm and SnapMirrors.pm use.
I'm still trying to track down the errors, since they only appeared when I added the functionality described above. I'll reply with a post-mortem as this unravels.
Thanks,
Chris | [reply] |
If you can educate your other team members in the ways of OO you will find that that can resolve many of these sorts of issue. Because you call methods on an object without needing to have it exported you can avoid import conflicts and circular module dependencies. From the perspective of someone using a module there is very little difference between a function call and a member call - just the $obj-> in front generally, and a call to new to create the object.
If you need any help sorting out simple OO let us know. It really is much easier than you may think.
True laziness is hard work
| [reply] |
True, I agree. I come from a C++ background, so it's not too hard for me, but the rest of the team is having problems with hashes of hashes, let alone trying to work with OO Perl.
Part of the reason for my modules was to simplify access to the data structures so the other admins could leverage the data. (Before, everyone would just create lists in their scripts, and then we'd have to maintain all of the lists in all the scripts, instead of one function in one location.)
It was a big enough fight getting people to realize how important using a module was, so I'm not sure I'm ready for the OO fight. I do agree, though. :)
Thank you again for all your comments. I really appreciate it.
Chris
| [reply] |