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)

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}

> 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.

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.

> 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.

This is neat stuff. Thank you!