in reply to extract all subroutines from .pm's and include in .pl

It is not easy as you think, if you do a simple copy of subroutines, in case if those subroutines use package variables which is initialized by another routine, it becomes messy. it is difficult to trace the depth of subroutines.

the Idea of packages is to make the main script look easy and simple and put all the reusable code and subroutines in packages, it seems that you have not understood that properly.

why can't you try exporter and include only those functions you require from those packages, this is one suggestion.

after saying this, another question arises in my mind, after how many subroutines we should look for moving it into a package, 5, 10 .. ?, i am not sure , so far i haven't defined more than two or three sub-routines in the main script, all the other statements are only function calling and flow control, but original functions would be got from modules.


Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
  • Comment on Re: extract all subroutines from .pm's and include in .pl

Replies are listed 'Best First'.
Re^2: extract all subroutines from .pm's and include in .pl
by meyerti (Novice) on May 18, 2009 at 12:39 UTC
    targetsmart!

    thanks for your an dall the other replies. i have indeed understood the usefullness of organising code in packages and subroutines and i do use it extensively (that's where my problem comes from). i just try to avoid copying all packages each time i want to pass on a small script to someone.

    exporter would still need copying the packages. i see the problem mentioned by others that it's not an easy problem, at least not as easy as i thought. e.g. for object oriented code one would at compile time probably not know which routines are going to be needed.

    anyway, i'll keep trying:)

      Don't think of spoiling your(Perl's/OOP) principle for the sake of ease of use of others(may be beginners/end-users/etc). Just give them a tar ball of your modules, main script and a README, this seems to be one of the good solution, as CPAN does normally.

      Vivek
      -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.