http://www.perlmonks.org?node_id=997412


in reply to How to export multiple packages in one file to another Perl program?

Thanks for all the replies. I know about the MixedCase notation, I use it myself. The use of abstract variable names and uppercase was only to indicate it could be any class name or variable. Let me rephrase the problem: Let's say I have a OO package called MyFiles which maintains some sort of list of files and it supports 3 ways of sorting. $BY_SIZE, $BY_USER, $BY_DATE. I could code 3 sort methods, or 1 sort method taking an extra parameter to indicate how it should be sorted. If I take the 2nd approach these constants have to be exported. I know how to do that using Exporter using EXPORT_OK, and I know I don't have to export any methods. Something like
package MyFile require Exporter; our @ISA = qw(Exporter); our $BY_SIZE = 0; our $BY_USER = 1; our $BY_DATE = 3; @EXPORT_OK = qw( $BY_SIZE $BY_USER $BY_DATE );
But I have multiple packages in one .pm file. And now I don't seem to be able to do this. If you say it is bad practice to have 1 method, consider than an object that returns a specific error message number. In that case also you would like to export the possible values of the error number as the programmer would be able to use that predefined value in his code rather than some vague number. In C you would put these values in a .h file. Considering the replies it seems that everyone recommends seperate files for each package. Something I find cumbersome for distribution. But it seems I have no choice.

Replies are listed 'Best First'.
Re^2: How to export multiple packages in one file to another Perl program?
by Tanktalus (Canon) on Oct 06, 2012 at 02:43 UTC

    "In C you would put these values in a .h file."

    In C, you wouldn't have multiple namespaces. That's the primary difference here.

    In C++, if memory serves, you could have multiple namespaces and then in your .cpp (or .cxx or whatever) file, you would have using std; using object1; ... and there's no way to auto-import a bunch of namespaces, and doing so in the header would defeat much of the purpose of namespaces (they don't export just small pieces like we can in Perl).

    And, in my experience, one tarball isn't any more cumbersome with one file in it or a hundred. :-) With very very few exceptions, I would say targeting a single file for deployment is misguided and/or optimistic. You'll end up with a config file, and maybe some data files (e.g., DDL for database deployment), and you'll quickly be beyond a single file anyway. May as well embrace the inevitable from the beginning. You'll also end up with code that's easier to write and maintain.

    It's not that you have no choice. It's that it will take you more effort to do than if you were to follow the convention. I do have a module I just wrote for $work the other week that does something similar to what you say. But it's definitely more work to set up than following convention. I've only done this this way because of some experience with our setup that says that this will make things a little easier as we keep forgetting to import some functions that we need nearly everywhere. Normally, that's not an issue, so for everything else, it's use Module; as normal.

    If you want MyThing to export the stuff from Object1, check out Import::Into. This might work:

    package MyThing; use Exporter qw(export_to_level); # no need for inheritance here. use Import::Into; # magic our @EXPORT = qw( $BY_SIZE $BY_DATE $BY_USER ); sub import { shift->export_to_level(1); # handle our exports Object1->import::into(scalar caller); # calls Object1's import metho +d but uses magic. } #... package Object1; # has to handle its exports here as if it were in its own file. 1;
    Still more work than normal, but probably will work. Though, again, if you don't know what you're doing, this probably isn't what you want. Use separate files.