in reply to Re^8: Undiagnosable Problem
in thread Undiagnosable Problem

I was afraid you were going to say that :)

I might as well move ALL code into Plx.pm, then, and just always use that all my scripts.

This is disappointing because I like to separate code into libraries for solely administrative reasons. When I'm working on Language Services, for instance, I think about a set of concepts common to all linguistic functions. Even if there are no global variables, it helps if all references to space available on a disk is always called SpaceAvailable rather than some being called SpaceAvailable and others called AvailableSpace.

Is there any way in Perl to segregate collections of functions this way, or must they always be lumped into a single master library?

Replies are listed 'Best First'.
Re^10: Undiagnosable Problem
by Corion (Patriarch) on Jan 15, 2017 at 19:43 UTC

    Usually, people use modules for that.

    If you feel that there is no way to partition your code by functionality to keep it in separate packages, maybe you can show us some code which you have problems to untangle.

    When dividing up functionality between modules, you will always have to strike the balance between separation and ease of use. The main advantage of putting everything into one module is that you only need one use statement at the top of your program to import all the functionality.

[reply]
[d/l]
      If Plx needs functions from PlxHml, and PlxHml needs functions from Plx, how exactly do I implement this? Thanks.
[reply]

        That's hard to say without actually seeing your code.

        You will have to identify the functions that are used from both places and move these into a third file which is loaded by both of the other files.

        I haven't encountered problems when doing that, but maybe you have two functions that invoke each other:

        sub foo {
    if( $_[0] ) {
        bar( $_[0] -1 )
    };
};

sub bar {
    if( $_[0] ) {
        foo( $_[0] -1 )
    };
};

        [download]

        These functions cannot be easily split in two, but depending on their functionality, maybe there is a way to rewrite them so that the common functionality can be removed.

[reply]
[d/l]
        PMFJI, but this sounds like your "dependency tree" is more like a "dependency mesh" and needs untangling…

        after reading Corion's post, I want to ask: If you draw a dependency graph "who calls whom", did you perhaps try to divide them not into branches or layers, but grouping them otherwise?

[reply]

In Section Seekers of Perl Wisdom