Modulinos and CPAN-appropriateness

[krazyk]

Recently, I've been developing Modulinos (as introduced by brian d foy in Mastering Perl [1]). Sometimes they contain functions that might be generally useful elsewhere (in addition to being useful as programs). Other times, the Modulinos are potentially useful to others as programs, but not so special for any subs they may export. In my consideration of whether or not to release them on CPAN, I'd like some guidance from the Monks.

One such modulino has already been released -- App::Smbxfer. I believe this one to be very worthwhile, as its exported functions could be useful and it provides uniquely valuable program functionality.

Others, however, don't seem as straightforward. For example, Linux::BootCleanup, a modulino to identify and archive files belonging to old kernels on a Linux system and to update bootloader menus accordingly. Though it might export a couple of functions, they are fairly trivial and would not independently warrant use of the module. Nonetheless, it is a useful piece of software, and as a modulino, it can utilize Perl's Test::* facilities, install in a standard way, etc. Also, the possibility exists that later versions may offer additional routines that would independently justify its use.

So, do useful "Modulino-tools" belong on CPAN even if they aren't useful for the module side of their identity?

[1] Mastering Perl
(UPDATED to fix title as corrected by brian d foy)

[brian_d_foy]

The C in CPAN is "Comprehensive". :)

The idea of a modulino is that there is a little run routine which you can use by default, but someone else can still use all of the subroutines and supporting code from the module if they like your application but want it just a little bit differently. They use your modulino but subclass it to change the run() subroutine and to override the parts they want to change.

Do do any of that they need to be able to get it, and that means putting it on CPAN. So, upload! :)

(Oh, and it's just Mastering Perl :)

[krazyk]

"They use your modulino but subclass it to change the run() subroutine and to override the parts they want to change."

This implies that the modulino is object-oriented ("subclassing" and "overriding"). Now, I'm not sure that you intended this statement to be taken that literally since some of your modulino demonstrations featured functional interfaces. However, it brings up some interesting considerations...

In Mastering Perl, you introduced "Modules as Programs" using a purely funcational module. In DDJ - Scripts as Modules, you introduced modulinos, recommending an OO style consisting entirely of class methods. This solely-class-method approach supports easy inheritance and overriding, but seems slightly less versatile when it comes to re-use of subroutines. For example, say Modulino::A has "run()" and helper function "buy()" so that buy() influences what run() does. Suppose that buy() is useful enough to be exported by Modulino::A for potential re-use. Suppose that Modulino::B wants to do exactly what Modulino::A does in its run method but to use a different buy()ing algorithm. If buy() is to be usable outside the modulino, it might be cleaner to design it as a plain function instead of a class method. Then buy() could be called as a regular function instead of PKG->buy()...
Read more... (2 kB)
Now we can cleanly inherit and override as well as export. This mixed interface style seems to me to be the most versatile way to build modulinos. The only problem is that ugly symbol table modification, but it would probably happen rarely and could be automated and abstracted by another module (which is why I'm so interested in finding the optimal pattern...I'm considering developing a module to aid in the construction of modulinos). What do you think?

[gamache]

The CPAN FAQ has no language against it.

I'd upload it, if for no other reason than to have an awesome install mechanism at no cost. If it grows to hold more externally-useful routines, great; if not, no harm done.

A Perl luminary advocated putting everything one writes on CPAN, but I forget who said it and where...

[Jenda]

I believe they do belong. Besides you never know what can be useful to others :-)

If nothing else, someone may create a more fancy interface to the same functionality using the functions from your modulino.

[Anonymous Monk]

hmmm...

if we now have Modulinos, perhaps by analogy with the neutrinos of nuclear physics, will we someday have Modulettos, similarly analogous to the now-obsolete neutrettos of nuclear physics?

[roboticus]

Charming idea ... but still a little strange. I'd vote it about 1/3 up. ;^)

...ropunicus

[petdance]

So, do useful XXX belong on CPAN even if they aren't useful for the module side of their identity?

Yes, yes, 1,000 times yes. You can't possibly know if something is going to be useful to anyone else. There's no "appropriateness" filter on the CPAN. If it could be useful to someone, put it out there.

I'll say it again: CPAN thrives BECAUSE of the unfettered uploading of everything, not in spite of it.

[krazyk]

Thanks, that's reassuring. As a new CPAN author, I want to do things in "one of the MTOrightWsTDI."

It does seem kind of strange to me to have a scripts area of CPAN since most scripts could be re-cast as modulinos. I guess it might be a bit overkill to turn anything really tiny into a modulino, though.