Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Can we have C-style Modularity?

by sumeetgrover (Monk)
on Jan 19, 2011 at 14:57 UTC ( #883134=perlquestion: print w/replies, xml ) Need Help??
sumeetgrover has asked for the wisdom of the Perl Monks concerning the following question:

I normally tend to write Perl modules only when I think they would be useful across different Perl scripts. But here's a question: When we write Perl modules, do we only write them when a pm would be used across different scripts implementing different tasks? OR Can we write Perl modules to group all the sub-functions within one script and put them in the module, so that what we get in the end is a C-programming style separation of sub routines? E.g., in C, you could call the program with the 'main' function as the 'Client' program and create another program that implements the sub-functions that the client can invoke. In this way, the client program simply invoke the services of the program implementing sub-routines. This also ensures that any change to the internal implementation of the sub-routine would require no change to the client program. Can we do the same in Perl using a perl module? Any thoughts would be much appreciated. Thank you!

Replies are listed 'Best First'.
Re: Can we have C-style Modularity?
by ELISHEVA (Prior) on Jan 19, 2011 at 15:16 UTC

    I'm not sure what you are asking. Do you want to know what you can do in Perl? What other people do do in Perl? Why something that makes sense isn't done more often at your workplace?

    I do whatever is most convenient and also keeps my variables close to the methods/functions/subroutines that use them. This is true whether I program in C or in Perl. Both languages provide file-wide scoped variables and thus result in similar programming patterns. In both Perl and C I use files to group cooperating functions and I use files to group together reusable units. I don't think I'm particularly unusual in this regard.

    In C programs one often groups cooperating functions together in a file so that variables shared by those functions, but not meant for general use by the whole application, stay nicely bundled together. In Perl one does the same thing. The only difference is the lingo. In Perl you declare a variable with file wide scope as a my variable outside of any function. In C you define it as a static variable outside of any function definition.

    Also whether in C or Perl, routines that are likely to be reused as a group will be placed in a single file. In C this makes building libraries easier. In Perl it makes for fewer use statements at the top of consumer modules.

Re: Can we have C-style Modularity?
by Anonyrnous Monk (Hermit) on Jan 19, 2011 at 15:06 UTC
    ... In this way, the client program simply invoke the services of the program implementing sub-routines.

    But that's exactly what you'd get with a normal Perl module, too... so why not simply implement one?

      Thanks for your reply.

      Agreed, that it's a Perl module and just do it. However, therein lies my question:

      Should a Perl Module only aim at re-usability across different scripts,
      Can it simply be used for the sake of 'Modularity' of 1 script, even if it might not be used by other scripts?

      Thank you!

        Either. There is more than one way to organize code. You are free to use modules in whatever manner makes the most sense for the organization of your own code.

        Should a Perl Module only aim at re-usability across different scripts,

        If you mean "Should a module only be written when it'll only be used by many scripts?", then the answer is no. Feel free to write modules that will only be used by one script.

        The way you phrased possibly indicates an intention to tightly couple the modules, and that's bad practice in any language.

        I don't see any problem using it only for the sake of modularity of one script :)

Re: Can we have C-style Modularity?
by afoken (Abbot) on Jan 19, 2011 at 16:52 UTC

    Do whatever fits your needs.

    I prefer to have short scripts. If the problem is small and special enough to be solved by a few routines stuffed into a single script file, I usually do exactly that.

    For larger problems, I prefer spreading my code over separate classes / packages / files, with a quite minimal loader script. Typically, I create a new (sub-)project in subversion, i.e. a directory containing at least the three subdirectories bin, etc, and lib. The loader script goes into bin, the perl packages into lib, and some kind of configuration file into etc. The loader script typically looks like this:

    #!/usr/bin/perl -T use 5.010; use strict; use warnings; use lib '/some/hardcoded/path/lib'; # or: #use FindBin; #use lib "$FindBin::Bin/../lib"; use Some::Prefix::MainClass; Some::Prefix::MainClass->main(@ARGV);

    Sometimes, there are several similar loader scripts for slightly different purposes, e.g. for programs that can be used both on the command line and via CGI / FastCGI.

    Sometimes, a set of classes becomes so useful that they end being installed as regular Perl modules. But most Perl modules I've written linger around in project specific lib directories and are only available to programs that manipulate their @INC, i.e. loader scripts.


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Can we have C-style Modularity?
by sundialsvc4 (Abbot) on Jan 19, 2011 at 16:25 UTC

    You certainly will see a variety of approaches used.   For instance, the Regex::Common package consists entirely of exported or exportable routines; as does Scalar::Util.

    By far the most common approach, however, is to build packages that implement Perl “objects,” using the notions of inheritance in those implementations.   This provides you with the functionality that you seek while also effectively dealing with the per-instance storage management issues that are naturally involved.   When you “create an object,” that object automagically knows what package(s) to refer to, and it automagically provides both its “methods” and a block of per-instance storage (a hash).   Well thought out.   Very nice.

    One of the mantras of Perl is TMTOWTDI = There’s More Than One Way To Do It.   And, that is certainly true.   Out of this, certain accepted “best practices” have clearly emerged.   (Adherence to them is “voluntary, but wise.”)

Re: Can we have C-style Modularity?
by cdarke (Prior) on Jan 19, 2011 at 22:40 UTC
    Yes, do it. However, a wise man once said "C programmers can write C in any language" (actually he said it about Fortran, but you get the idea). Consider if you are doing it because it is a good idea in C, or because it is a good idea in Perl.

    Can and should are not the same thing, the answer to almost any "Can I" question in Perl is "YES". Should you? If it gets the job done, then yes. If it means you are happy, then yes also. But not just because it is like some other language.
Re: Can we have C-style Modularity?
by thezip (Vicar) on Jan 20, 2011 at 03:57 UTC

    I often write modules just so that I don't have to look at subroutine code anymore. By giving my module subroutines descriptive names and reasonable interfaces, I can abstract the subs to do very useful things without having to worry about the details therein.

    I'm a big fan of "less code to look at" while solving the larger problem, so my knee-jerk reaction is to ship it off somewhere else.

    What can be asserted without proof can be dismissed without proof. - Christopher Hitchens

      Thank you!

      I completely agree! In software design, such a programming style (as you might be aware) is called ADT (Abstract Data Types) and I am a big fan of it!

      Cheers guys.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://883134]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (12)
As of 2018-10-16 15:02 GMT
Find Nodes?
    Voting Booth?
    When I need money for a bigger acquisition, I usually ...

    Results (85 votes). Check out past polls.