in reply to Difference between executing and "using" a .pm file

Generally speaking, a modulino uses the .pl extension and is included in a library context with a require (as in, require '/path/to/my/modulino.pl';). If you already have a bonefide module as .pm, then you'll necessarily want to create a commandline driver that will use this module, handle commandline arguments, then do something useful with the functionality encapsulated with the module. You don't want to put the caller check in file scope of the .pm then call that .pm as you would a .pl script.

So to make your use case consistent with a modulino approach, rename your .pm to .pl; keep the caller based context dispatching and you can call your .pl script a modulino.

But this is sort of going backwards. Like I said above, if you have a .pm file already; just use it in a .pl. The whole point of a modulino really is ephermal; sure they can be long lived, but it's most useful when refactoring legacy code bases into a modular/library centric approach.

Another characteristic of your .pm not being a fully encapsulated module (and maybe inappropriately serving as a modulino) is if you have any commandline argument processing anywhere in it - be it ad hoc, Getopts or what have you. This sort of @ARGV munging typically belongs exclusively inside of a .pl (including one that is a modulino).

Replies are listed 'Best First'.
Re^2: Difference between executing and "using" a .pm file
by pryrt (Abbot) on Mar 30, 2021 at 20:27 UTC
    Generally speaking, a modulino uses the .pl extension

    Interesting. Because the modulino link I provided was actually in my browser history because of your Re: Need to know the process to implement perl script into web application server.... and that link you provided shows a file named examples/modulino.pm and he runs it as perl modulino.pm. So it's not completely unheard of to have the modulino as a .pm, not a .pl

    It seems there are really two use cases for modulino:

    1. having a script, and wanting to slowly turn it into a module (ie, your use case)
    2. having a module, and wanting to do something without having to write a separate .pl to call it, like validate, test, or run under default conditions (ie, the case that gszabo seems to be espousing in the article, and that Marshall wants and LanX gave examples of)
    Both seem reasonable uses of the concept, to me.
[reply]
[d/l]
[select]
      I think this

      Rescue-legacy-code-with-modulinos

      is the central article on the topic with a lot of links and historical context. Especially b/c Brian states that he didn't invent but popularized the concept. (he even cites a Perlmonks' thread as earliest reference for the term "modulino")

      He describes it primarily as a way to perl Module.pm with a meaningful effect. (A)

      But in the second part of this article he describes the other way round from initial require script.pl to renaming pl -> pm at the end. (B)

      I.O.W. how he's using this technique to transform legacy code into modules.

      Actually that's quite a interesting and powerful strategy. I'm certain I've seen this article multiple times before, but can't remember reading this part anymore.

      And I think that's not surprising. We have to realize that this (B) direction involves far more refactoring, while the former (A) can be already achieved with just one single additional line.

      I'd say it's safe to say that >95% of all modulinos out there belong to the A-category of runnable modules, and that's what the majority remembers.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

[reply]
[d/l]
[select]
      > he runs it as perl modulino.pm

      I didn't realize that, but that just goes to show you TIMTOWDI :). And I agree with your use cases above; though I use it often for case #1 and have never had the need for #2. Thank you.
[reply]
Re^2: Difference between executing and "using" a .pm file
by Marshall (Canon) on Mar 30, 2021 at 20:35 UTC
    You wrote: "If you already have a bonefide module as .pm, then you'll necessarily want to create a commandline driver that will use this module, handle commandline arguments, then do something useful with the functionality encapsulated with the module.".

    Yes, that is actually what I have now, except that there are no command line arguments. If there were any command line args, then I would keep what I have (a very short driver program). All of this code that spews out explanations to the user about the config file is already part of the object. This is not a module test target, it is more analogous to a regex decompile thing.

    At the end of the day, I may or may not do this. But if I want to do it, I know how to do it. This is actually not a "big deal" either way. I have already released the 6th year code and as such this is more of an academic question. However major revisions are planned for year #7. I've got months to think about this. I just wanna understand the options that I have.

[reply]
      > I just wanna understand the options that I have.

      Very good. Obviously don't take my tone to mean this is the only use them or way to do it. I like talking about modulinos any chance I can get, though. Neat stuff.
[reply]
        This is neat stuff. Thank you!
[reply]

In Section Seekers of Perl Wisdom