Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Re: Confused about splitting program into multiple files.

by disciple (Pilgrim)
on Feb 15, 2004 at 01:26 UTC ( #329074=note: print w/replies, xml ) Need Help??

in reply to Re: Confused about splitting program into multiple files.
in thread Confused about splitting program into multiple files.

Thanks. I have read about modules and am aware of that particular method. The concern I have is this. The "module" I will be creating will contain about 40 functions for accessing data from a database. I would like to have all the functions I write to automatically be available instead of explicitly exporting all ~40 of them.

Should I assume then that there is not another preferred method of doing what I want to do?

  • Comment on Re: Re: Confused about splitting program into multiple files.

Replies are listed 'Best First'.
Re: Re: Re: Confused about splitting program into multiple files.
by ctilmes (Vicar) on Feb 15, 2004 at 02:40 UTC
    Well "preferred" doesn't really apply, but if you want to do what you are saying, just put "package main;" at the top of the 'module' instead of some other package name.

    Your main program is package main, and by putting your module's subroutines into package main, they are automatically available for you without exporting.

    You probably don't want to here this, but I'll reiterate what the docs and other commenters say. You should really do it the right way and segregate things into separate packages and export only symbols that need to be.

      Thank you for your response. This is exactly what I was looking for. I wanted to know if there was another way to do it, and you pointed out that there is, but that it is not recommended and therefore not the preferred way.

      I am curious though, if every function is going to be available (exported) is there a reason not to put them in package main?

        You have it backwards. It is not recommended because it is not preferred, and not vice versa.

        The next question is why it is not preferred. Several reasons:

        1. If a script uses multiple modules that autoexport lots of stuff, it quickly gets hard to figure out where any given function came from. Give users the option to enforce sanity by documenting what came from where.
        2. When independent modules put things into package main, it becomes very easy for private functions in one to conflict with private functions in another. Tracking down and resolving these conflicts grows more complex rapidly as the number of functions and files grows. (With 5 files you only have 1/4 the number of possible lines of conflict as you do with 10.) Putting each file in its own package reduces the damage from such internal conflicts.
        3. It is preferred that you not export every function. Good modularity in procedural code is to have each module have a simple API. A ton of exported functions is a very complex API.
        There are more reasons, plenty of them, but those will do for now. If you want the rest, along with plenty of other good advice, I can highly recommend Code Complete. (No, that is not a Perl book. But good programming technique is not Perl-specific.)

        Yes, you can do what you ask for. Perl gives you enough rope to hang yourself. But that doesn't mean that you should do it...

        UPDATE: I used the word "recommended" where I really meant "preferred".

        ...if every function is going to be available (exported) is there a reason not to put them in package main?

        One reason could be code reuse. If the same functions are used across several scripts, you at minimum save a little typing by keeping them in a separate file where they can be pulled in by all the scripts that need them.


Re: Re: Re: Confused about splitting program into multiple files.
by rchiav (Deacon) on Feb 15, 2004 at 02:14 UTC
    You're saying the reason you don't want to use a module is because you don't want to copy and paste 40 function names into the @EXPORT array? I'd think you spent more time here trying to find a different way than it would have taken to copy and paste those function names to begin with.

      You are correct that in this instance I have spent more time here trying to find if there is a preferred way to do what I want to do. However, this is something I will be and have been doing on a semi-regular basis.

      It is a maintenance issue as well. Everytime you add a function, you must add it to the export line. I don't want to do that but if there is no other preferred means of using functions from another file, then I will.

      Besides, can you really blame me for asking if there is a quicker/easier way? Aren't we all looking to make our programming lives a bit easier?

        Aren't we all looking to make our programming lives a bit easier?

        In my experience, it is easier in the long run not to export everything into main::. Objects aren't perfect, but they tend to organize things.

        For small programs, it likely doesn't matter. Once I get over twenty or thirty functions, though, it really starts to matter very quickly.

        No, I don't blame you for asking. And yes, we're all looking for a quicker, easier way to do things. But I think the one thing you're missing here is that Perl and the use of modules, by design, does not export functions and variables. You say this is a maintenance issue. Having all those functions in main:: is also a maintenance issue.

        You mention that you work with C# and .NET. The recomendation there is to also use full namespaces when refrencing properties, methods and objects. As you'll notice, Visual Studio .NET generates full namespace paths. The difference is that .NET makes it easier to not do so.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://329074]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2021-10-22 04:48 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (85 votes). Check out past polls.