Re^3: error for undefined function that's been imported

I'm not sure whether you've benefitted as much as you'd like from rincewind's discussion, but in my own (less than fully experienced) opinion, Bob9000's point is the more pertinent one. If I see a code base being built up with packages like this:

## file: SomeModule.pm ##

package SomeModule;
#...
use OtherModule;
#...
__END__

## file: OtherModule.pm ##

package OtherModule;
#...
use SomeModule;
#...
[download]

my first reaction is "don't do that", and my next reaction is "this is crying out desparately for refactoring".

Cross-references like that turn your code into a sort of "chicken-and-egg" problem -- if not in terms of actual compilation troubles, then at least in terms of ongoing maintenance. When someone else comes along to fix or add something, they have to go around in circles to track what the code is doing (and that "someone else" could very well be you, six months from now).

The main point of creating modules is to encapsulate things that are logically independent of other things. Having mutual dependencies among modules just defeats their purpose.

Look at the functions defined in "MyUserProfile.pm" that are called from "Register.pm", and likewise at those defined in the latter that are called from the former. If you can put these functions into one or more distinct modules, and have the two original modules use the new ones instead of using each other, things will be easier all around.

Ideally, this should lead you in the same direction that rincewind suggested: an OO design. If a current module is based on certain data being shared by its various subs, you have an obvious basis for making that into an object; if not, then just dividing up the subs a bit differently to eliminate module cross-dependencies should be fairly easy and sufficient, and will reduce incoherence in your code.

Comment on Re^3: error for undefined function that's been imported Download Code

Replies are listed 'Best First'.
Re^4: error for undefined function that's been imported by argv (Pilgrim) on Aug 18, 2005 at 17:06 UTC
The main point of creating modules is to encapsulate things that are logically independent of other things. Having mutual dependencies among modules just defeats their purpose. While this is true, it's simplistic to think that just because something is encapsulated into its own module that it doesn't somehow rely on other modules that do entirely different things. This is the whole spirit of libraries, as opposed to objects and classes. I'm sure I don't have to remind most of the readers here that there's nothing wrong or unusual about library functions that may call back and forth between themselves, nor is it always the case that one needs to build class hierarhcies just to have a series of independent functions that have no common ancestors to one another, but which are still separated into discrete files from one another because their abstraction paradigms are entirely different. While I'm a fan (and implementor) of object-oriented programming (I've written two books on the subject for ORA), I also know when not to use an elephant gun when all I want to kill is a mouse. Surely, there must be a way in perl to have a series of modules that have variables and functions that can be exported and used by other modules, while also being able to import such from other modules, all without having the kind of mess I'm running into here. Given these set-backs, I can only assume that, perhaps, "use" and "module" are not the way to make generically exportable and inter-dependent library functions, but that some other method is perhaps more suited. Either that, or perl needs a way for a module to declare a function as type "no-really-I'm-global-and-this-time-I-mean-it." Dan Heller http://www.danheller.com	[reply]

Replies are listed 'Best First'.

Re^4: error for undefined function that's been imported
by argv (Pilgrim) on Aug 18, 2005 at 17:06 UTC

The main point of creating modules is to encapsulate things that are logically independent of other things. Having mutual dependencies among modules just defeats their purpose.

While this is true, it's simplistic to think that just because something is encapsulated into its own module that it doesn't somehow rely on other modules that do entirely different things. This is the whole spirit of libraries, as opposed to objects and classes.

I'm sure I don't have to remind most of the readers here that there's nothing wrong or unusual about library functions that may call back and forth between themselves, nor is it always the case that one needs to build class hierarhcies just to have a series of independent functions that have no common ancestors to one another, but which are still separated into discrete files from one another because their abstraction paradigms are entirely different. While I'm a fan (and implementor) of object-oriented programming (I've written two books on the subject for ORA), I also know when not to use an elephant gun when all I want to kill is a mouse.

Surely, there must be a way in perl to have a series of modules that have variables and functions that can be exported and used by other modules, while also being able to import such from other modules, all without having the kind of mess I'm running into here. Given these set-backs, I can only assume that, perhaps, "use" and "module" are not the way to make generically exportable and inter-dependent library functions, but that some other method is perhaps more suited. Either that, or perl needs a way for a module to declare a function as type "no-really-I'm-global-and-this-time-I-mean-it."

Dan Heller
http://www.danheller.com

[reply]