in reply to Re: modules as data files
in thread modules as data files

thanks for the quick reply.

1) in the script, the variable $data is undeclared. doesn't it require an explicit package name?

2) it appears that the script is still required to know the name of the hash in the module?

3) i don't follow the use statement in the script. i can only use "files"; you are using a file _and_ a data structure. ( in fact, my perl copy reflects this as the $pm variable is uninitialized. )

Replies are listed 'Best First'.
Re^3: modules as data files
by dragonchild (Archbishop) on Oct 10, 2005 at 04:18 UTC
    1. See my response to #2.
    2. Yes - this is part of the interface that the module publishes to the rest of the world. In fact, it's the whole reason the module exists. You had the same thing in your initial version. Mine just makes it a little more explicit.
    3. use Foo ('bar', 'baz'); is actually* implemented internally as so:
      BEGIN { require 'Foo.pm'; Foo->import( 'bar', 'baz' ); }
      The command that brings a file into your code is "require". "use" wraps require and adds a little something to it. Now, in my code, Exporter goes ahead and provides a import() method for you, expecting to use the @EXPORT_OK array to find stuff to bring from use'd namespace to the use-r. That's how $data makes it over from test0 to main.
    You might be confused by the funky syntax. That's because I'm doing an eval. You could replace the eval with the equivalent
    (my $filename = $pm) =~ s{ :: }{ / }gx; require "${filename}.pm"; $pm->import( '$data' );
    It's a bit harder to read, but you might put that into a subroutine called my_use() and call it that way. (There's a CPAN module that does this for you, but I don't remember its name off the bat.)

    * Well, not exactly, but the exact details would only get in the way.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?